4 ms·

Never quite understood the attraction of dependency injection frameworks. Sure pass in your dependencies as an interface via some sort of constructor, but why

Never quite understood the attraction of dependency injection frameworks. Sure pass in your dependencies as an interface via some sort of constructor, but why all the frameworks to do so? Why all the complexity with hard to debug magic strings, annotations and finding out what's missing from the classpath at runtime? Just seems as a very complicated way to avoid creating package c that brings together package a and dependency b in a simple class that creates b and passes it into a. What am I missing?

HexDecOctBin 2y ago
> What am I missing? Job Security.
mrkeen 2y ago
I second this. The original value proposition of DI (dependency inversion) was that you could write your tax logic and unit-test it without the code knowing that it's talking to MySQL. Injecting your dependencies into your constructor makes dependency inversion possible. That messaging has somehow become smeared across dependency injection, frameworks, classpath scanning, autowiring, reflection, annotations etc. 20 years ago, DI meant that your TaxCalculator didn't know about your database. Today, DI means that your TaxCalculator still knows about your database, but now it knows about Spring too.
wink 2y ago
> Never quite understood the attraction of dependency injection frameworks. Many years ago there was a running joke that a "dependency injection framework" in PHP was a single array with stuff in it. Then it all became much more java-like.
tored 2y ago
Dependency injection containers can be overly complex and allow complex configurations, too much magic. That is why I kept my container library simple, you read thru all the source in less than 15 minutes. What I like about it is that it is natural to use composition with classes, it encourages to create classes to divide your application into reusable parts. And with my library all you do is to put the dependent class in the constructor. My library can without much effort be replaced with normal factory, that is by design. Warning PHP https://github.com/paketphp/bero https://github.com/paketphp/bero

HexDecOctBin 2y ago

> What am I missing? Job Security.

mrkeen 2y ago

I second this. The original value proposition of DI (dependency inversion) was that you could write your tax logic and unit-test it without the code knowing that it's talking to MySQL. Injecting your dependencies into your constructor makes dependency inversion possible. That messaging has somehow become smeared across dependency injection, frameworks, classpath scanning, autowiring, reflection, annotations etc. 20 years ago, DI meant that your TaxCalculator didn't know about your database. Today, DI means that your TaxCalculator still knows about your database, but now it knows about Spring too.

wink 2y ago

> Never quite understood the attraction of dependency injection frameworks. Many years ago there was a running joke that a "dependency injection framework" in PHP was a single array with stuff in it. Then it all became much more java-like.

tored 2y ago

Dependency injection containers can be overly complex and allow complex configurations, too much magic. That is why I kept my container library simple, you read thru all the source in less than 15 minutes. What I like about it is that it is natural to use composition with classes, it encourages to create classes to divide your application into reusable parts. And with my library all you do is to put the dependent class in the constructor. My library can without much effort be replaced with normal factory, that is by design. Warning PHP https://github.com/paketphp/bero https://github.com/paketphp/bero