¿Que son los principios SOLID?
Los principios SOLID son unos principios de diseño de software. Son unas convenciones recopiladas de varios autores que se siguen para mejorar el desarrollo del software. Están aceptados por las grandes industrias, ya que permiten hacer un código mantenible en el tiempo, ampliable y testable.
Son 5 principios, uno por cada letra, y que se desglosaran uno a uno:
- SRP. Principio de Responsabilidad Única (Single responsibility principle): Una clase, Una responsabilidad. Un objeto solo debería tener una única razón para cambiar.
- OCP. Principio de Abierto/Cerrado (Open/closed principle): Las clases deben estar abiertas para su extensión y cerradas para su modificación.
- LSP. Principio de sustitución de Liskov (Liskov substitution principle): Los objetos deberían ser reemplazables por otros subtipos sin alterar el correcto funcionamiento del programa.
- ISP. Principio de segregación de interfaces (Interface segregation principle): Divide y venceras. Es mejor muchas interfaces específicas que una interfaz general.
- DIP. Principio de inversión de dependencias (Dependency inversion principle): Mejor depender de interfaces y no depender de implementaciones.
Siguiendo estos principios, el software desarrollado será más tolerante a cambios y a la evolución tempora. Son cruciales en la programación orientada a objetos. Estos criterios permiten a los desarrolladores crear software de calidad, huyendo de los conceptos de grandes arquitecturas y haciendolo más dinámico.
SOLID Vs STUPID
En contraposición a los principios SOLID se muestran los principios STUPID, que son utilizados de manera indebida a lo largo del tiempo en el desarrollo del software:
- Singleton: Este patrón se usaba hace años. Es un objeto que contiene todo. No muestra las dependencias de una clase, haciendo difícil la detección del acoplamiento entre clases.
Es perjudicial para la comprobaciones y los test, al no poder aislar las funcionalidades. - Tight Coupling: Acoplamiento entre clases. Clases que están muy ligadas entre sí y que impide la mantenibilidad y la tolerancia a cambios.
- Untestability: Código difícil de testear. Clases que utilizan librerias y métodos que no permiten realizar pruebas al no poder mockearlas. Con la inyección de dependencias se podrán realizar las pruebas unitarias deseables.
- Premature Optimization: El pensar a futuro y creer que se necesitarán ciertos requisitos hace que se desarrolle software complejo. Es mejor desarrollar los casos de uso deseables y luego ir creciendo. Para ello la creación de interfaces es esencial.
- Indescriptive Naming: Se nombran clases con variables y atributos indescriptibles al tener varias utilizaciones. Mediante la creación de clases con responsabilidad única mejoraremos también las noenclaturas.
- Duplication: Duplicidad de código. En infinidad de casos se copiaba y pegaban lineas de código, dando lugar a una situación en que un cambio en alguna de esas lineas era imposible de asumir.
