Dependency Injection vs Dependency Inversion vs Inversion of Control

Introduction

Oftentimes developers confuse between the patterns – Dependency Inversion (DIP), Inversion of Control (IoC) and Dependency Injection (DI) and assume both are the same. These are similar in concept but talk about different things. In this article, let us pit each of these against one another and see how they are related (dependency injection vs dependency inversion vs inversion of control).

What is Dependency Inversion?

Dependency Inversion is one of the 5 SOLID principles. This principle talks about how components must not communicate with each other directly but rather be called using abstractions, calling for reducing Coupling and flexibility. 

For example, If some component FooService must call a method getFoo() inside FooRepository, it must not call FooRepository directly but instead use an abstraction of the FooRepository, say IFooRepository that defines the method getFoo()

Observe that it only talks about how the interactions must happen, it’s a principle – a theory.

What is Inversion of Control?

Inversion of Control (IoC) is an architectural pattern, which states that custom code must not decide which components to call directly but instead be decided by an external system. This system in the real world is called the “IoC Container”. 

Hence if some component FooService must call a method getFoo() inside FooRepository, it must not create an object of the FooRepository directly, but instead let the container provide an object of the FooRepository, so that it can then call the method getFoo() from that object.

Observe that here the context has now shifted from the dependency to how the dependency instantiation needs to be handled. Again, this is an architectural pattern, which different frameworks handle in different ways. IoC only talks about who controls the flow and instantiation of dependencies.

What is Dependency Injection?

Dependency Injection (DI) is an implementation of how the dependencies are provided to the requesting component by the “Container”. DI is a specific form of IoC, where the Container can provide an instance of the requested type to the requesting component. Here the approaches differ in different frameworks, but there is 1 common way in any framework – via the constructor. 

If some component FooService must call a method getFoo() inside FooRepository, it needs to let the “IoC container” provide it the required object in some way. It can have a parameterized constructor that takes a parameter of type IFooRepository and the “IoC container” can then “Inject” an object of type IFooRepository into the component.

Observe that here the context has now shifted to how the object needs to be provided to the requesting component. Again, depending on what framework we are using, the number of ways can differ. Majority of the Container frameworks support Constructor Injection, while few support Property and Method injection based on how they are being defined.

Dependency Inversion vs Inversion of Control vs Dependency Injection – Comparison

Dependency Injection is the implementation of Inversion of Control, where the framework manages the provision of dependencies. It follows Dependency Inversion along the way.

Be it Spring Container for Java or .NET Container for C# – these concepts are all one and the same. It’s just how these are related to one another and how one follows upon another internally.

To summarize, always remember that –

• Dependency Inversion is a Principle, a part of the SOLID principles and pitches for reducing Coupling and improving flexibility
• Inversion of Control is an Architectural Pattern, that pitches to externalize the control over provision of dependencies for loosely coupled components
• Dependency Injection is an implementation of Inversion of Control (IoC) while following Dependency Inversion Principle. It figures out how to provision dependencies for requesting components.