Dependency Inversion Principle explained

Dependency inversion principle (aka DIP) is defined as follows:

A. High-level modules should not depend on low-level modules. Both should depend on abstractions.

B. Abstractions should not depend on details. Details should depend on abstractions.

It is really easy to find this definition on the Internet. I guess most readers heard about it and some even know it by heart. Unfortunately, it is pretty vague and it takes quite some time researching to get it. This is why I decided to write this article.

First, why is it important?

Dependency is always a risk that needs be assessed and managed. Tight coupling with low-level implementation details makes it harder to manage dependencies and protect the most important part of an application, namely business logic. It may lead to:

• collateral damage to high-level modules coming from changes in low-level modules
• reduced testability and refactorability of code
• contamination of business logic with implementation details of low-level modules
• limited reusability of high-level modules

Let’s get back to the definition and try to refine it.

High-level modules are modules of high importance containing business logic of an application. High-level modules know what needs to be done. In other words, they contain identity of an application.