This is the last article related to the set of SOLID project principles. The DIP principle is the most useful of all in terms of its relevance to the creation of strong classes and good architecture of the whole system.

What can go wrong?

When we create the classes or other code structures, they will always depend on other elements, such as:

• The libraries included in the framework.
• The libraries from other suppliers.
• Other elements of the system

It is not too hard to guess that the above classification comes from the extent of the variability of the elements, which our class depends on. We can easily state that the elements of the framework will be the least variable. The perfect example is the string class. Its implementation is practically invariable. On the other hand, there are obviously further elements of the system that are being created in the meantime – they can be modified during the whole software programming cycle. The libraries of the other suppliers should also be treated as variables. For this simple reason that there might be a need for them to be changed. Relating the class for instance, to the variable elements, brings the risk of modification in other dependent elements.

The Adjustments

We can’t avoid the situation where our classes are independent from other partial elements of the system. By introducing a small change into our code we can achieve much better stability of our system. Our classes should depend not on the specific implementations but only on the abstracts, on the interfaces.

Abstract and the interface

We should always treat the abstract classes and the interfaces as a solid and invariable element. When programming the system we should design the main interfaces and basing on them – build the correlation between the classes or modules. Each component of the system would then depend on the invariable elements.

Where does the name come from?

In order to understand well why the principle was named a dependency inversion one, it is good to take a look at the two charts below, mentioned previously during the first project principle explanation:

We talked about a hypothetical  module to manage the employees. To avoid the necessity of the whole system’s modification we introduced then the façade project prototype. The other elements of the system will still depend on that façade though, which will again depend on the specific implementations: HourReporter, EmployeeSaver and PayCalculator. By introducing the new interfaces we will obtain the following chart:

The flow of the information will obviously remain the same. The direction of those dependencies will change though. It is shown on the picture by the inverted direction of the arrows, which represent the dependencies, and this inversion became the principle’s name. Now the EmployeeFacade and HourReporter, EmployeeSaver and PayCalculator depend on the interfaces, which can be characterized by the significant level of invariability.

The significance to the architecture

The described principle is very useful during the creation of systems’ architecture. As I mentioned before, it helps to introduce to the system the solid independent elements, which will affect the specific implementations, combining that way the classes (or even the modules) which are not strongly linked together. It also helps to draw the boundaries for the modules. Using the above chart one can determine the module line between the interfaces and their implementation. This way we will obtain the module responsible for managing the employee related operations, independent of any specific implementation of these operations (the left side) and the module responsible for very specific operations. This module will only have to provide a few methods of specified functionality, but without the indication of how it is supposed to be processed. Such a module can be easily improved and developed or even removed.

The summary

The Dependency Inversion Principle helps to create softly bonded classes. In the wider meaning it supports the design of system architecture, correlation between the modules and helps to establish the boundaries between them. Dear Reader, I hope that from now on the SOLID principles will be much more useful and understandable to you!

Other SOLID principles:
Single Responsibility
Open-Closed
Liskov Substitution
Interface Segregation