SOLID Principles
The acronym SOLID refers to a set of principles in software development that guide us on how to organize functions and structured data in classes, and how these should interconnect. These five principles aim to make the code more understandable, flexible, and maintainable.
These principles were created by Robert C. Martin in a paper from the year 2000 called "Design Principles and Design Patterns" and are part of a larger group of principles and best practices promoted by him. Each letter of the acronym refers to a different principle.
The objective of these principles lies in the creation of mid-level software structures (module level) that have the following characteristics:
- Adaptability to change
- Clarity and ease of understanding
- Serving as a foundation for additional components
Single Responsibility principle
The single responsibility principle means that a class should only have one job or responsibility. This means that there should only be one reason for a class to change. Classes with many responsibilities are difficult to maintain.
Single Responsibility Principle in object-oriented design
Open Closed principle
This principle states that entities (classes, methods or functions) should be open for extension but closed for modification. That an entity is open for extension means that it is possible to change the behavior of that entity. On the other hand, being closed for modification means that it should be possible to change the behavior without modifying the original source code.
Open-Closed Principle in Object-Oriented Design
Liskov Substitution principle
This principle states that objects of a program can be replaced by their subtypes without altering the correct functioning of the program. That is, an argument of a function or method that accepts a class or interface should work the same with any subtype of the same class or interface. To make this possible, it is necessary that the signature of the implemented or overridden methods be the same and do not add or change the TYPE of the function result (including exceptions).
Principio de Sustitución de Liskov en diseño orientado a objetos (SOLID)
Interface Segregation principle
This principle states that a client should not force the implementation of an interface that it does not use. Said another way, many client-specific interfaces are better than one general-purpose interface. If a method or function receives a dependency that implements other methods that are not of interest, segregation should be performed and a specific interface created.
Principio de Segregación de Interfaces en diseño orientado a objetos (SOLID)
Dependency Inversion principle
This principle states that dependencies should be given by abstractions rather than concrete classes. It is perhaps one of the most difficult principles to understand and refers to decoupling the code. Functions or methods should not depend on concrete classes, as this generates coupling with the low-level code implemented in that class; instead, dependencies should be given at a high level, i.e., with abstract classes or interfaces.
Principio de Inversión de Dependencias en diseño orientado a objetos (SOLID)