How to apply SOLID Software Design Principles to Spring Boot Application (Part 5)
DIP: Dependency Inversion Principle
(skip the first paragraph if you have already read other parts of this blog series)
This article is the last part of the blog series, dedicated to well-known software design principles, that evolved over time and were finally summarised by Robert C. Martin with initials of the corresponding principles. These principles guide us how to build well-designed software systems, giving best practices for arranging classes, functions, building blocks. We will look at each principle in depth and apply it to the Spring Boot Application. The idea is refactoring existing software based on these principles from architectural point of view.
The word S.O.L.I.D. stands for:
- SRP: Single Responsibility Principle
- OCP: Open-Closed Principle
- LSP: Liskov Substitution Principle
- ISP: Interface Segregation Principle
- DIP: Dependency Inversion Principle
This fifth part is about DIP. Before jumping to concrete example, let’s have some theory.
Dependency inversion principle is when dependency modules are reversed, thus rendering high-level modules independent of the low-level module implementation details.
For a software system, ideal world is when a maximum flexibility is achieved. DIP states exactly this: source code dependencies should import only abstractions. High-Level components should connect to Low-Level components, preferably through abstractions. And abstractions should not depend on details, details should depend on abstractions.
It should also not be forgotten that there is a fundamental difference between Dependency Inversion Principle and Inversion of Control(IoC), although the basic idea is the same. IoC is engaged more in framework level (For instance, how Spring Boot handles bean initialisation), whereas DIP should be part of programmers’ everyday activity.
Some important advises from R.C.Martin concerning Dependency Inversion Principle are following:
- Don’t refer to volatile concrete classes
- Don’t derive from volatile concrete classes
- Don’t override concrete functions
- Never mention the name of anything concrete and volatile (a little bit utopic)
Good solution for DIP might be Abstract Factory Design Pattern. Please have a look at Design Patterns for more Information.
But it is not possible to build a software system completely on abstractions. There are and there will be definitely classes with concrete imports. The goal should not be to avoid it completely, but always being careful with volatility of classes when building object oriented design relationships.
In a practical part, we are not going to extend our cash flow management application, since we already implemented DIP automatically at several places.
Above is the final version of Class Diagram for cashflow.core.* packages. By taking closer glance at class structure, the one might see that Dependency Inversion Principle is already applied at Converter, Calculator and Repository Service Interfaces.
For more in-depth understanding please have a look at corresponding git branch.
This was the fifth and last part of SOLID Principles.
