The main reasons to use a fancy dependency-injection mechanic:
1) You have not learned how constructors work.
2) You have not learned how to break circular dependencies.
3) You really like global variables.
4) You are using a framework created by someone suffering from 1, 2, or 3 above.
@GeePawHill
6) You've got way too many dependencies.
@GeePawHill
5) the only tool you have is that specific hammer, so everything looks like a nail
When I've wanted to use (code in the style of) Dependency Injection (DI), but was not allowed to (due to nonsensical corporate restrictions), I found that I could easily write code that does DI without needing to be data-driven or using reflection. That is, I can write code that creates instances of other classes and "wires them together" — using local variables and constructor parameters in the most obvious ways.
Dependency Injection (DI) with no "framework" is easy to do!
@[email protected] I can kind of grudgingly be convinced they are OK in situations where your system needs to allow for both externally created plugins and has non-trivial life cycle management.
I just often (although not quite universally) feel that the wrong decision in that case was when you decided you needed that system, rather than the DI.
