SOLID Principles in Pictures
If you are familiar with object oriented programming, you probably heard about SOLID principles. These five rules for software development set the path to follow when you write programs to make them easier to scale and maintain. They gained fame thanks to the programmer Robert Martin.
There are many excellent articles on the Web that talk about the principles of SOLID, but I hardly came across illustrated among them. Because of this, it is difficult for people with a penchant for visual perception of information – such as myself – to grasp the essence and not be distracted.
The main goal of this article is to better understand the principles of SOLID through drawing illustrations, as well as determine the purpose of each principle. The fact is that some of the principles seem similar, but the functions perform different. It may happen that you follow one principle and violate the other, although in appearance there is not much difference between them.
To make it easier to read, I only mention classes here, however, everything said in the article also applies to functions, methods and modules, so keep that in mind.
SOLID Principles
S – Single Responsibility
Each class should be responsible for only one operation.
If a class is responsible for several operations at once, the likelihood of bugs increases – by making changes regarding one of the operations, you yourself, without suspecting it, can affect others.
Appointment
The principle serves to separate the types of behavior, due to which errors caused by modifications in one behavior did not extend to other types that are not associated with it.
O – Open-Closed (Open-Closed)
Classes must be open for expansion, but closed for modification.
When you change the current behavior of a class, these changes affect all systems working with this class. If you want the class to perform more operations, then the ideal option is not to replace the old with new ones, but add new ones to existing ones.
Appointment
The principle serves to make the behavior of the class more diverse without interfering with the current operations that it performs. Thanks to this, you avoid errors in those code fragments where this class is involved.
L – Liskov Substitution (Barbara Liskov Substitution Principle)
If P is a subtype of T, then any objects of type T present in the program can be replaced by objects of type P without negative consequences for the functionality of the program.
In cases where the child class is not able to perform the same actions as the parent class, there is a risk of errors.
If you have a class and you create another class on its basis, the original class becomes the parent, and the new one becomes its descendant. The child class must perform the same operations as the parent class. This is called heredity.
It is necessary that the descendant class be able to process the same requests as the parent and produce the same result. Or the result may differ, but at the same time be of the same type. This is shown in the picture as follows: the parent class serves coffee (in any form), which means that it is acceptable for the descendant class to serve cappuccino (a type of coffee), but it is unacceptable to serve water.
If the descendant class does not satisfy these requirements, it means that it is too different from the parent and violates the principle.
Appointment
The principle serves to ensure constancy: the parent class and the descendant class can be used in the same way without disrupting the program.
I – Interface Segregation
The client should not be dependent on methods that he does not use.
When a class has to perform actions that do not carry any real benefit, this translates into a waste of resources, and if the class is unable to perform these actions, it leads to bugs.
A class should perform only those operations that are necessary for the implementation of its functions. All other actions should either be deleted completely or moved if there is a chance that they will be needed by another class in the future.
Appointment
The principle serves to split a single set of actions into a number of smaller sets – thus, each class does what is really required of it, and nothing more.
D – Dependency Inversion (Dependency Inversion Principle)
Top-level modules should not be dependent on lower-level modules. Both those and others should depend on abstractions. Abstractions should not depend on the details. Details should depend on abstractions.
To begin, I will explain the terms that are used here, in simple words.
Top-level modules (or classes) = classes that perform the operation with the tool
Lower level modules (or classes) = tools needed to perform operations
Abstractions – represent an interface connecting two classes
Details = specific tool performance
According to this principle, the class should not be connected to the tool that it uses to perform the operation. Instead, it should be connected to an interface that helps establish a connection between the tool and the class.
In addition, the principle states that neither the interface nor the class are required to delve into the specifics of the tool. On the contrary, this tool should fit the requirements of the interface.
Appointment
This principle serves to eliminate the dependence of upper-level classes on lower-level classes by introducing interfaces.
Summarizing what was said
We examined all five principles and formulated an assignment for each. All this is designed to help you write code that can be modified, expanded and tested with a minimum of problems. Thanks for reading; I hope you got no less pleasure than I did in the process of working on the article.
