Dependency Injection: What Happened to Good Old-Fashioned Refactoring?

Question

DI creates an extra layer of abstraction, so if your implementation class ever changes, you can simply connect another class with the same interface.

But why not just reorganize if you want to use a different implementation class? Other languages ​​like Python and Ruby work just fine. Why not Java?

Answer 1

This is an incorrect characteristic of dependency injection. It's not that you have one implementation of a particular interface that changes over time; rather, it is possible that there will immediately be many different implementations of the interface, and which implementation will be used may vary depending on several different program runs. For example, in your real program you can use one implementation, while during unit testing you can “lure” this implementation with an alternative version that is easier to test. In this case, refactoring is not a solution, because you should be able to test all the time without interrupting the rest of the development process.

It should also be noted that dependency injection is usually used as a solution for the Singleton anti-pattern; it allows you to have a singleton object that can be easily ridiculed during testing. And, if it later becomes clear that the single-point assumption is really wrong, then singleton can be replaced with various implementations.

Some resources that may be useful for a better understanding of the topic:

• Guice Java: Dependency Injection Java-Way
• Great modular Java with Google Guice
• Singleton are pathological liars
• Why singletons are evil
• The root cause of the singleton
• Injection Dependence Myth: Walkthrough

Answer 2

So, you say that Python and Ruby cannot have dependency injections? Or Java can't work fine without DI?

In addition, you missed one of the most specific DIs that you can have Dynamic DI, not only at compile time, but at runtime. There is always a question in Software Engineering whether there is too much abstraction and too little, and in fact it all comes down to how you develop a solution to your problem.

Answer 3

Not really. The problem here is that when you write a piece of code, for example:

Runnable r = new MyFooRunnable(); 

you essentially decide that Runnable you will need MyFooRunnable (and not MyBarRunnable or the third). Sometimes you want to defer this decision from compilation time to deployment time, so the installer can decide how the individual application modules are made up of should be glued together.

This has traditionally been done with factories, but it only moves the actual solution around in the code, and you still need to know all the possibilities when coding a factory or let it read the instructions from the configuration file (which is usually fragile for refactoring).

Dependency Injection is a formalization of configured factories in such a way that the code does not need to know anything about how everything works. It also explains why annotations were so useful for indicating where dependency injection should occur. If during code execution in a non-DI installation (for example, the JUnit test), then there is nothing (which would be difficult to do with factories clogged throughout).

Thus, the Injection Dependency, used in a broad sense, allows you to write modules that are “well-bound” to each other without knowing about each other at compile time. This is very similar to the concept of a jar file, but more time has passed for ripening.