> “This implementation is difficult to unit test.” Horsepucky. You can still have dependency injection without a framework. Just make a constructor that takes the dependency as an optional parameter. Done. Applause. Early lunch.
Ok so it's specifically the frameworks that's disliked.
> Furthermore, dependency injection frameworks encourage you to think in terms of globals. That’s what they inject! A single, globally-configured instance of a class. Think about it. If you one day want two different instances of an injected variable, you’ll need an impact driver to express just how screwed you are. This has all kinds of knock-on effects in terms of reducing encapsulation and separating state from behavior.
I would expect any decent DI framework can name things when you want different flavours.
The only real problem I've had was with slow startup using Spring/Boot which I blame on DI auto/scanning.
In spring, you can have multiple beans (=DI object instances) of the exact same class/interface. You can define one as primary and have to give them different names.
You can also automate bean creation per thread, per request, per session or whatever else floats your boat. Instance/bean persistence is easy too, if you really want to go that far (you should not).
For regulatory reasons, I once even had to implement a datasource selector for spring, that would pick the database connection based on userId.
Why do people that have zero idea about what they are writing find so much attention on hacker news?
Try Dagger, it generates DI code during build. So it's kinda hard code, but the framework does it for you. So the startup is much faster, and easier for JIT compiler to reason (no reflection)
The first dependency injection framework i learned was Nucleus [1]. An unusual feature of Nucleus is that it has no type-based autowiring. You write a little properties file for every component, and to inject a component into another, the recipient uses the path to the other component's properties file. It is shockingly basic, but it works really well. Everything is explicit, but simple enough that it's not laborious to use. Having multiple instances of components is trivial, because they're just separate properties files. Indeed, the driving use case for Nucleus, the ATG commerce framework (since bought by Oracle) had multiple instances of many classes (eg the generic ORM repository class, for different siloes of data). I was really surprised when i first used an autowiring dependency injection framework, where this is either impossible, or you have to jump through hoops to do it.
Ok so it's specifically the frameworks that's disliked.
> Furthermore, dependency injection frameworks encourage you to think in terms of globals. That’s what they inject! A single, globally-configured instance of a class. Think about it. If you one day want two different instances of an injected variable, you’ll need an impact driver to express just how screwed you are. This has all kinds of knock-on effects in terms of reducing encapsulation and separating state from behavior.
I would expect any decent DI framework can name things when you want different flavours.
The only real problem I've had was with slow startup using Spring/Boot which I blame on DI auto/scanning.