La programación orientada a objetos nos permite diseñar componentes reusables y hacer software mantenible. Sin embargo estos componentes a menudo deben interactuar con otros, entonces lo que hacemos es añadir dependencias a otros componentes lo que termina anulando los beneficios de la POO.
El nombre SOLID , acuñado por Robert C. Martin, viene de 5 principios que tienen como propósito diseñar software mantenible y capaz de evolucionar en el tiempo. Si bien estos principios son validos por si mismo, en la práctica suelen verse relacionados (https://lassala.net/2010/11/04/a-good-example-of-liskov-substitution-principle/).
- Single responsibility principle
- Open/closed principle
- Liskov substitution principle
- Interface segregation principle
- Dependency inversion principle
Single responsability principle (SRP)
El principio de responsabilidad única es tal vez el más conocido y más fácil de entender, consiste en que un componente debería tener sólo una responsabilidad, la cual debe ser capaz de satisface por completo. Este principio se asemeja a «Do one thing and do it well» de la filosofía unix.
Mantener el SRP provee a nuestro software de un desacoplamiento que facilitará la evolución del mismo. En caso contrario, al momento de tener que modificar una responsabilidad del software, podemos impactar en otras que se encuentren acopladas. De la misma manera, un componente desacoplado puede ser utilizado en otros contextos sin tener que realizar modificaciones en el.
The Open-Closed Principle (OCP)
El principio abierto-cerrado significa que un componente debe estar abierto a ser extendido en su funcionalidad, pero cerrado a ser modificado.
Un componente abierto a ser extendido, nos permitirá extender la funcionalidad definida sin necesidad de modificar el código fuente existente, la cuál es una regla de diseño, a excepción claro, que no queramos que dicho componente pueda ser extendido.
Un componente cerrado a ser modificado, nos proveerá de confiabilidad, ya que sabemos que este no será, deliberadamente, cambiado por otro componente.
Liskov substitution principle (LSP)
El principio de substitución de Liskov toma su nombre de Barbara Liskov (si, una mujer), y dice que, toda clase B heredada de una clase A, puede ser utilizada para remplazar la clase A en un programa, sin que este pierda su funcionalidad o sin que este se de por enterado.
* Es por esto que en Java al sobrescribir un método no podemos declarar una excepción checkeada , que no haya sido declarada por el método padre 😉
Interface segregation principle (ISP)
El principio de segregación de la interfaz dice que las interfaces deben ser específicas, de tal forma que sus implementaciones sólo conozcan los métodos que realmente necesitan usar.
Siguiendo el patrón «Header Interface», dónde una interfaz es una representación de los métodos públicos de una clase (para poder darle otras implementaciones), se corre el riesgo de violar el ISP, dado que esta clase podría cumplir más de un rol. Al contrario, el patrón «Role Interface», si cumple con el ISP, ya que en este caso, manejamos una interfaz por cada rol que cumple la clase (https://martinfowler.com/bliki/RoleInterface.html).
Dependency inversion principle (DIP)
El principio de inversión de la dependencia, es, a grandes rasgos, depender de abstracciones y no de clases concretas.
En el diseño tradicional, las clases de alto nivel tienen dependencia hacia componentes de más bajo nivel, lo que limita su mantenibilidad y reutilización. Este principio indica que tales dependencias deben ser hacia abstracciones de estos componentes.
Referencias:
path 347 