Dependency Inversion Principle VS Dependency Injection

Several years ago, when I started programming, I used to confuse these two and in some cases, I thought they were the same. Although they are not unrelated!

In this article, I want to define these two things more.

Dependency injection and dependency inversion are both important concepts in software design, Grasping these principles is crucial for engineers to build adaptable and enduring systems. These principles guide developers away from monolithic structures towards modular, loosely coupled architectures, with a deep understanding of their intricacies, interdependencies, and practical applications.

Dependency Inversion Principle (DIP)

The Dependency Inversion Principle is one of the principles of SOLID, A design principle that states high-level modules should not depend on low-level modules. Both should depend on abstractions. Abstractions should not depend on details. Details should depend on abstractions. In my opinion, it is based on these basic design principles "Program to an interface, not an implementation".

Uncle Bob says in his famous book Clean Code:

The DIP says that ourclasses should depend upon abstractions, not on concrete details.

Before going to the definition of DI, it is necessary to mention another concept called IOC.

Inversion of Control (IoC)

In the Inversion-of-Control (IoC) pattern, instead of directly controlling the flow, you hand over control to an external handler by providing a callback function. This callback defines how the handler should react. It is derived from the concept of DIP.

Inversion of Control moves secondary responsibilities from an object to other objects that are dedicated to the purpose.

Dependency Injection and Service Location are techniques that implement the Inversion-of-Control (IoC) pattern.

Dependency Injection (IoC)

In Dependency Injection (DI), objects receive their required dependencies through constructor injection or property injection. This is typically handled by a framework component, removing the need for the object itself to be responsible for creating its dependencies. it's a powerful mechanism for the implementation of IoC.

True Dependency Injection goes one step further. The class takes no direct steps to resolve its dependencies; it is completely passive. Instead, it provides setter methods or constructor arguments (or both) that are used to inject the dependencies. During the construction process, the DI container instantiates the required objects (usually on demand) and uses the constructor arguments or setter methods provided to wire together the dependencies. Which dependent objects are actually used is specified through a configuration file or programmatically in a special-purpose construction module.

The Spring Framework provides the best-known DI container for Java.