SOLID — Dependency Inversion

In this article, we will discuss the principle of dependency inversion. If you stumbled upon this article without any prior context, I recommend going back a few steps and starting with the first article, as this is the last of the five articles on SOLID. Before reading this article, it is essential that you are familiar with: Single Responsibility, Open-Closed, Liskov, and Interface Segregation.

The Principle

The Dependency Inversion Principle (DIP) is one of the five SOLID principles, a set of software design guidelines aimed at facilitating the creation of more flexible, scalable, and maintainable systems.

In simple terms, the Dependency Inversion Principle suggests that high-level modules should not depend directly on low-level modules. Instead, both should depend on abstractions. In other words, high-level classes should not depend on specific implementations of low-level classes, but rather on interfaces or abstract classes.

This approach allows for greater flexibility and extensibility within the system. When dependencies are inverted in this way, it becomes easier to replace individual components without affecting the rest of the system. Additionally, it makes testing easier, as dependencies can be easily simulated or replaced with mocks during unit tests.

In summary, the Dependency Inversion Principle promotes the creation of more modular, flexible, and loosely coupled systems, facilitating the maintenance and evolution of the software over time.

Therefore, if you use statically typed languages or those that require import or include statements, you should always point to abstract source modules; nothing in your code should point to concrete elements.

But how to manage all of this? This is where some design patterns like Abstract Factory come in to help you connect the entire “ecosystem” of your code. Below we see an example image.

The central line divides the concrete part of the code, meaning the files that contain actual logic, from the abstract part that contains only declarations and nothing more. Notice that the “Impl” part, which is the real implementation, points to the interfaces and the upper part of the system. In other words, the main flow of the application points to the opposite side of the real code implementation, and that is why the principle is called dependency inversion.

Do you agree? Disagree? Did you like it? Leave your contribution by liking or commenting :).