A modern programming language that makes developers happier.

kotlinlang

<@U6AHR4J4R> KTOR is probably recommended - I did not start my project using it though, maybe later on I'll transfer it over

You could also look into <#C0BLU9K96|kodein> for DI if you don't like Dagger2 or want something simpler, once used to it it's great, and it's also MultiPlatform. In Spring, there's already DI built-in, so I thought it useful to mention this...

For a simple project I'm simply using Kotlin objects instead of dependency injection and it works great :stuck_out_tongue:

That's not just for a simple project. Manual DI is appropriate on any sized project - and if it starts to look too big then that's a signal.

Simple project, agreed... but most start simple and evolute to a big mess, and when you get to testing, things start getting....

And by using auto-DI you're just masking that problem.

True, but with the simpler frameworks that start up quickly I'm mostly using integration testing anyway so singleton objects work nicely for the most part

..I hand-wire external collaborators but that's about it

... and therefore avoiding the introduction of pointless interfaces (those with just a single implementation) and an excess/misuse of mocking

I never understood the point to XML-based DI in particular. What's the difference between that and a static initializer class, other than that the XML file has no compile time type checking?

Annotations at least do provide the "magic" of not having to be explicit anywhere, but I'm not fully convinced that's an upside

I use Spring Boot and I dont have any pointelss interfaces with single implementations

mocking frameworks could mock concrete classes in like 2008, can't comprehend why people keep parroting this nonsense

also XML based DI hasn't been used since years ago in Spring

Annotation based DI just ramps up the "magic" and introducing the most trivial DI conditions becomes a huge expedition into Spring-land at best, or impossible at worst

Just last month at my work we wanted to introduce a condition to not initialize certain beans if a particular boolean property was set to false

But Spring was setting up the beans before initializing the variable, so it was `null` and unreadable in the `Conditional` annotation

I luckily convinced them to just initialize the bean but short-circuit all its operations to no-ops, rather than trying to delve into the bowels of Spring autowiring

I'm less bearish on mocking frameworks :slightly_smiling_face:  but have also noticed they're very seductive to junior devs

Conditional bean loading is the key feature that allows for something like Spring Boot to exist, so there must be a way to do it.

I know how I would do it in a static initializer class! `if (condition) { bean = TheBean(); } else { bean = null; }`

I just mentioned this because Ktor doesn't have it's own DI, contrary to Spring... but each one has his own habits :smile: 