[shawabawa3]

> What DI should make possible is you modify only componentA, to state that it now depends on serviceB, and as long as you have a serviceB available then you don't need to change your "wire up my application" code at all

So... instead of modifying just the "wire up my application" code, you modify just the componentA code. In return you get to fill your code with magic so nobody can see where serviceB is created.

[lmm]

You always have to modify componentA - you're adding a new feature to it, and declaring that it takes a serviceB. If you're not using DI you have to change your "wire up my application" code as well.

The choice is between writing the wiring code yourself, which means a lot of boilerplate that's basically irrelevant to the functionality of your application, or have it happen implicitly, which yes involves a certain amount of magic. But even polymorphic functions are "magic" on some level.

[PommeDeTerre]

In practice, the automatic "wiring-up" often breaks, and in any sizable system it quickly becomes very difficult and time consuming to track down and fix such breakages.

Things can become even worse when the libraries or frameworks you're using end up having bugs in them that interfere with the dependency injection they're performing.

Too many times I've seen very experienced and capable developers lose hours, and even days in some cases, dealing with dependency injection issues. Just one of these incidents, which will happen in any serious project, will far exceed the time and effort it would've taken to write the equivalent code by hand.