My favourite take on DI is this set of articles from like 12 years ago, written by a guy who has written the first DI framework for Unity, on which are the currently popular ones, such as Zenject, based on.

The first two articles are pretty basic, explaining his reasoning and why it's such a cool concept and way forward.

Then, there's this update:

Followed by more articles about why he thinks it was a mistake, and he no longer recommends or uses DI in Unity in favor of manual dependency injection. And I kind of agree - his main reasoning is that it's really easy for unnecessary dependencies to sneak up into your code-base, since it's really easy to just write another [Inject] without a second thought and be done with it.

However, with manual dependency injection through constructor parameters, you will take a step back when you're adding 11th parameter to the constructor, and will take a moment to think whether there's really no other better way. Of course, this should not be an relevant issue with experienced programmers, but it's not as inherently obvious you're doing something potentially wrong, when you just add another [Inject], when compared to adding another constructor parameter.

[–] docAvid@midwest.social 4 points 5 months ago

Exactly. Dependency injection is good; if you need a framework to do it, you're probably doing it wrong; if your framework is too magical, you're probably not even doing it at all anymore.

[–] tatterdemalion@programming.dev 13 points 5 months ago (1 children)

Say what you want about DI frameworks, but if I have to remove another fucking global variable so I can write a test, I'm going to cut a bitch.

[–] cadekat@pawb.social 7 points 5 months ago (1 children)

Dependency injection is so much worse. Oh, hey, where'd this value come from? Giant blob of opaque reflection code.

[–] Zagorath@aussie.zone 4 points 5 months ago (2 children)

It can be used in bad ways, but if it's used in the right way you should never have the situation you just described.

[–] cadekat@pawb.social 2 points 5 months ago (1 children)

I'm not exactly sure what you mean. Doesn't all dependency injection work the way I described?

Without being familiar with the framework, you can't trace your way from the class getting injected into to the configuration, even if you're experienced with the language.

[–] Zagorath@aussie.zone 2 points 5 months ago (1 children)

I don't think so. When I've seen it done it's usually not been random values injected (except when those values are secret keys which should absolutely not be stored in code to begin with), it's usually injecting a service. Another class, usually with a name that makes it easy to trace down. Like if you're building an OrderService, that might take as a dependency an IProductService, which would have injected into it the class ProductService (personally, I don't like the Hungarian notation that C# uses, but it's a convention and my preference for sticking to strong conventions for the sake of consistency outweighs my distaste for Hungarian notation). That's easy to find, and in fact your IDE can probably take you straight to it from the OrderService's constructor.

[–] cadekat@pawb.social 1 points 4 months ago (1 children)

I'm using value in the loosest sense, like how all objects are values.

So now if you have three implementations of IProductService, how do you know which one is configured?

[–] Zagorath@aussie.zone 1 points 4 months ago

It's easy to imagine a hypothetical way that could lead to problems. But in all the code I've worked with, either that scenario is avoided entirely, or other context makes it absolutely clear which IProductService is being used.

[–] grrgyle@slrpnk.net 1 points 5 months ago

Same could be said of a global. There's a time and a place for each.

One thing I'll say is I don't remember us needing a team of senior+ devs to handle web app back in the day...

[–] Krakaval@jlai.lu 9 points 5 months ago (3 children)

Can we talk about annotations which are broken when you upgrade spring boot ? You are asked to upgrade some old application to the newest version of spring boot, application that you discover on the spot, the application does not work anymore after the upgrade, and you have to go through 10 intermediate upgrade guides to discover what could possibly be wrong ?

[–] agressivelyPassive@feddit.de 6 points 5 months ago (1 children)

Spring annotations in general. There's a completely hidden bean context where every annotation seems to throw interceptors, filters, or some reflection crap into. Every stacktrace is 200 lines of garbage, every app somehow needs 500mb for just existing and if you add something with a very narrow scope, that suddenly causes something completely unrelated to stop working.

Realistically, DI and all the Spring crap does not add anything but complexity.

[–] Phunter@lemm.ee 1 points 5 months ago

Our Spring service was so simple until we decided we needed annotations to handle the fetching of settings. Now we are corrupted with needless reflection.

[–] isVeryLoud@lemmy.ca 4 points 5 months ago (1 children)

Holy shit mood, described to the tee.

An application I've never heard or seen before that needs to be upgraded, and it breaks, so you now need to understand what the hell this application does so you can fix it properly.

[–] Krakaval@jlai.lu 2 points 4 months ago

And the management not getting why it takes so long to « just update some version numbers in Pom.xml files »…

[–] frazorth@feddit.uk 2 points 5 months ago

Gradle, with it's transitive dependency modifications is a huge pain in this area.

It used to be that if a library ended up having a flaw then it would be flagged and we would get the dependency updated. These days security block the "security risk" and you have to replace your dependencies dependency. Fingers crossed you can get it to actually test all the code paths.

If an second level project gets a flaw, and it's used indirectly then we should really look at getting the import updated so that we know it works. If that import is abandoned then we should not be updating that second level dependency, either adopt and fix the first level dependency or look at an alternative.

[–] MajorHavoc@programming.dev 8 points 5 months ago

I'll never plaster the back of my car with stickers that all proclaim the same things in ALL CAPS.

But if I was going to...

It would pretty much match this meme.

[–] Lmaydev@programming.dev 5 points 5 months ago

I love dependency injection personally.

I managed to completely change how YARP routed requests by registering a single interface.

The flexibility it provides is awesome. And it makes testing so much easier.

[–] deadbeef79000@lemmy.nz 5 points 5 months ago

Urgh. I just sicked in my mouth.

Die in a hole DI frameworks.

I already have an injection 'framework' it's called a constructor. I already have a factory it's called new

[–] grrgyle@slrpnk.net 4 points 5 months ago (1 children)

DI: ☺️

DI frameworks: 😒

[–] deadbeef79000@lemmy.nz 3 points 5 months ago

I just DI all the time, it's called a constructor.

[–] ulkesh 3 points 5 months ago

…and the wheel turns again…

[–] koncertejo@lemmy.ml 2 points 5 months ago

As an audio engineer, I was very confused about what this had to do with Direct Injection for a second.

[–] pkill@programming.dev 1 points 5 months ago (1 children)

[–] deadbeef79000@lemmy.nz 1 points 5 months ago

It came over the wire as text! How did you turn it into that?

Gold.