When we are learning to program for the first time, our attention is only focused on making the system functionality as expected, and we do not pay too much attention to structural or architectural details that may be relevant in the future. Once we know how to program, our interest now is that in addition to making the system work, the code is as clean as possible, since we are interested in being able to modify or add new code in the future.
But all systems grow and the number of people in the team increases, we realize that no matter how hard we try to have everything in order, there is a moment when we feel that the system gets out of control and becomes a monster difficult to maintain and extend. That is why the right way to create systems is to do it thinking in terms of architecture. Understand that we are not simply giving functions to the computer, but that we are creating a complex system of instructions and requirements.
When we talk about software architecture, one of its pillars is the SOLID design principle, defined by its creator Robert C. Martin in his book Clean Architecture: "The SOLID principles tell us how to arrange our functions and data structures into classes, and how those classes should be interconnected"
The functionality of this principle is to allow us to have code that is easier to understand, can tolerate change, and whose parts can be reused in some other system.
The name SOLID is determined by the initials of the following principles:
- Single Responsibility Principle: A piece of code should do only one thing.
- Open-Closed Principle: Software entities should be open for extension but closed for modification.
- Liskov Substitution Principle: Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it.
- Interface Segregation Principle: Many client-specific interfaces are better than one general-purpose interface.
- Dependency Inversion Principle: Depend upon abstractions, not concretions.
The purpose of this design principle is to guide us in the task of building systems much more efficiently and at the same time with a structure capable of supporting both changes in the behavior of the system and in the way in which the pieces of the system communicate with each other, because as its creator says:
"Good software systems begin with clean code. On the one hand, if the bricks aren't well made, the architecture of the building doesn't matter much. On the other hand, you can make a substantial mess with well-made bricks"