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.
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.
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.
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.