Because code becomes harder to understand.
replyWith direct dependencies, if you are trying to understand some code that calls some function and what it does exactly isn't completely obvious, you can press a button to go to it, understand it, and come back.
With dependency injection it depends on what is going to be inserted during runtime, so you can't.
If you can press a button to understand what is going on, "it’s possible to overuse" most definitely applies. Dependency injection, as the name implies, is for dealing with dependencies — things that you cannot observe until runtime.
replyHence the benefit to testing; allowing you to inject a deterministic implementation while under test.
Unless you mean just regular constructor parameters, dependency injection in the sense of a runtime dependency injection framework is the one thing I try to avoid like the plague.
replyThat is called a "DI Container", and usually manages the objects and order of instantiation etc.
replyDependency injection simply means to take objects as parameters, and not instantiate them themselves (which causes "Inversion of Control" also commonly mentioned when talking about DI). DI Containers just makes the managing of objects easier.
Avoiding it like a plague seems excessive, did you have a bad experience with them?
When Martin Fowler coined the term Dependency Injection [0], that was specifically for the context of container instrumentation. Merely passing service objects as constructor parameters is more akin to the Strategy pattern. At least in the Java world where it originated, “dependency injection” has always been about wiring application components and services together at runtime based on configuration, often directly injecting the dependencies into object fields via reflection, and not about statically compiled constructor invocations that happen to pass service objects.
reply