SOLID is an acronym for a set of object-oriented programming principles described by Robert C. Martin.
These are not immutable rules or absolute truths; rather, they are good advice. They serve to name concepts and not just rely on the “feeling” of bad code. They aim to categorize these “feelings” into specific recommendations.
(S)ingle Responsibility
The Single Responsibility principle states that each object should have one and only one responsibility. This also implies that it has a single reason to change.
(O)pen-Closed Principle
Principle attributed to Bertrand Meyer. An object is open for extension but closed for modification. This indicates that class design should allow for maximum reuse without the need to change existing code. While inheritance is the most common use case, it can also be achieved through well-thought-out interfaces and composition.
(L)iskov Substitution Principle
The Liskov Substitution principle states that if a class is extended, all subclass instances should be usable as if they were instances of the base class.
(I)nterface Segregation Principle
The Interface Segregation principle means that classes should not depend on methods they do not use. When a class uses an interface, it should ensure that it will use all the methods defined by that interface. The goal is to avoid interfaces defining more than what is actually needed. The simplest way to determine compliance with this principle is if there are empty methods when extending the interface. The solution is to split the interface into more specific interfaces and only use the one that is truly needed.
(D)ependency Inversion Principle
This principle talks about decoupling classes:
A. High-level classes should not depend on low-level classes. Both should depend on abstractions.
B. Abstractions should not depend on details. Details should depend on abstractions.
What does this mean?
It aims to prevent domain classes (high-level) from being mixed with the framework used (implementations), for example.
Object creation is done through creation patterns like factories or dependency injection.
All package-private classes should be connected through an interface.
A SOLID Conclusion
When working on new functionality or reviewing existing code, I try to review these principles to assess their adherence. It is not necessary for all of them to be followed or to change the code in a way that hampers development just to comply with them. The idea is to always remember the problems they try to avoid, adding a small enhancement to our development.
Referencias
https://devexperto.com/principio-responsabilidad-unica/
https://sites.google.com/site/unclebobconsultingllc/getting-a-solid-start
http://mil-oss.org/resources/objectmentor_design-principles-and-design-patterns.pdf
https://en.wikipedia.org/wiki/Dependency_inversion_principle
Be First to Comment