DIP: Dependency Inversion Principle

Introduction

This is the 11th article in the System Design and Software Architecture series. In this article, we are discussing the sub-topic of the design principle, DIP: Dependency Inversion Principle.

What is The Dependency Inversion Principle?

The general idea of the Dependency Inversion Principle is as simple as it is important: high-level modules that provide complex logic are easily reusable and do not affect changes to lower-level modules that provide utility features. To achieve that, you need to introduce abstractions that decouple the high-level and low-level modules from each other.

According to Robert C. Martin’s definition, the dependency inversion principle consists of two parts:

• High-level modules do not depend on low-level modules. Both must rely on abstractions.
• Abstractions should not depend on details. Details should depend on abstractions.

The Details Depend on the Abstract

An important detail of this definition is that it relies on the abstraction of high-level and low-level modules. The design principle not only changes the direction of dependence, as you might expect when you first read its name. It divides the dependence between high-level and low-level modules by introducing an abstraction between them. So in the end, you get two dependencies:

1. The high-level module depends on the module abstraction.
2. The low-level module depends on the same abstraction.

High-level Modules

High-level modules are the part that brings real value to our application. They are modules written to solve real problems and use cases.

They are more abstract and map the business domain. Many of us call this business logic. Whenever we hear the word business logic, we turn to the high-level modules that provide the features of our application. Top-level modules tell us what software should do, not how software should do it.

Low-level Modules

Low-level modules are the implementation details needed to execute business policies. As high-level modules tend to be more abstract in nature, at some point, we will need specific elements that will help execute our business policies. They are the plumbing for the interior of a system. They tell us how the software should perform different functions. Therefore, high-level modules tell us what software should do, while low-level modules tell us how software should execute different tasks.

For example:

• Logging, Data Access, Network Communication, and IO.
• Abstractions
• Something non-concrete.
• Something we cannot “instantiate.” In Java applications, we tend to format abstract models using interfaces and abstract classes.

Dependency Injection is the implementation of the Dependency Inversion Principle.

One way in which the Open-Closed Principle can be achieved is by using the Dependency Inversion Principle.

The top-level modules in the DIP are the modules that appear at the top of the UML diagram and depend on the abstract layer. In the center of the diagram are the abstractions. The lower-level modules are at the lower level of the diagram and are concrete implementations of the abstract layer.

Introduction to Dependency Injection

Dependency injection is widely used in line with the Dependency Inversion Principle. However, they are not the same thing. Let’s take a look at how PaymentProcessor depends on this class.

Dependency injection is a technique that allows the creation of objects that depend on a class externally.

We have different ways to do this. One of them is the use of common sets to establish those dependencies. However, this is not a good approach, as it can cause objects to become tightly coupled.

Types of Dependency Injection

This can be done by using dependency injection:

• Constructor injection
• Field injection
• Method injection

Inversion of Control

The inversion of control allows us to create a larger system by removing the responsibility of creating objects.

The inversion of control is the design principle that gives control of object design, configuration, and life cycle to a container or framework.

Controlling the creation and management of objects is reversed from the programmer to the framework. We no longer need to create new objects ourselves. Something else creates them for us, and this something else is commonly referred to as an IOC container or a DI container. Controlling object creation is reversed. It is not the programmer but the container that controls those objects. It makes sense to use it for certain objects in an application, such as services, data access, or controllers.

However, for entities, data exchange objects, or value objects, it does not make sense to use an IOC container. We can simply instantiate those objects, and from an architectural point of view, it is correct.

There are many benefits to using an IOC container for our system.

• First, it makes it very easy to switch between different implementations of a particular class at runtime.
• Then, it increases program modularity.
• Last but not least, it manages the life cycle of objects and their configuration.

Advantages

• Loose coupling
• Easy testing
• Better layer separation
• Interface-based design
• Dynamic Proxy (AOP for cross-cutting concerns)

Architecture

Dependency inversion has an architecture that is key to its definition. In each domain, it is the most important and most abstract. It shows the communication protocol between domains and defines the remaining packages or libraries.

Clean Architecture

In clean architecture, the domain is located in the center. If you look at the direction of the arrows indicating the dependency, it becomes clear what are the most important and stable layers. The outer layers are considered unstable tools, so avoid relying on them.

Hexagonal Architecture

It is similar to hexagonal architecture, with the domain also located in the center and the ports being abstractions of communication from outside the domain. Here again, it is clear that the domain is more stable, and traditional dependency is reversed.

Editing Dependency Inversion Pattern Normalization

In many projects, the Dependency Inversion Principle and pattern are considered to become a single concept that needs to be generalized and applied to all interfaces between software modules.

There are at least two reasons for this:

• It is simple to see a good thought principle as a coding pattern. After encoding an abstract class or interface, the programmer may say: “I have done the abstract work.”
• As most unit testing tools depend on inheritance for mocking, it has become the norm to use standard interfaces between classes (not just between modules when using generality makes sense).

If the mocking tool used is based on inheritance, it is necessary to apply the Dependency Inversion pattern extensively.

This Has Major Drawbacks:

• It is not enough just to implement an interface across a class to reduce coupling; just thinking about the potential abstraction of interactions can lead to a less connected design.
• Implementing common interfaces everywhere in a project is difficult to understand and maintain. At each step, the interface will ask itself what other implementations of this interface are, and the response is usually none.
• Factories that typically rely on a dependency-injection framework require more plumbing code to normalize the interface.
• Interface generalization limits the use of programming language features.

Conclusion

Thanks for reading the article DIP: Dependency Inversion Principle as an essential component in system design and architecture.

Originally published at https://onloadcode.com on April 5, 2021.