[Aeolun]

When applied without thinking about why. Yes.

Except dependency injection. I really can’t imagine why you’d ever not use that. I suppose it’s possible to overuse, but you’d still have better code than without. Certainly more testable code.

[Scarblac]

Because code becomes harder to understand.

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

[9rx]

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.

Hence the benefit to testing; allowing you to inject a deterministic implementation while under test.

[Aeolun]

With dependency injection your interface always describes what your implementation can do. If you see the interface and you have to care what is going to happen when you use it you are doing it wrong.

[layer8]

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.

[oldestofsports]

That is called a "DI Container", and usually manages the objects and order of instantiation etc.

Dependency 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?

[layer8]

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.

[0] https://martinfowler.com/articles/injection.html