Introducción a los principios SOLID
Historia y Propósito
Los Principios SOLID son un conjunto de cinco principios de diseño orientado a objetos introducidos por Robert C. Martin, a menudo conocido como “Uncle Bob”. Estos principios se introdujeron para promover un diseño de software más entendible, flexible y mantenible. El acrónimo SOLID representa cinco principios fundamentales que pueden ayudar a los desarrolladores a evitar malas prácticas de diseño, como el acoplamiento rígido y las dependencias frágiles.
Los 5 principios SOLID
-
S - Principio de Responsabilidad Única (Single Responsibility Principle): Cada bloque de control (clase, interface, método, variable…) debe tener una sola responsabilidad y esa responsabilidad debe estar encapsulada por la estructura de control. Esto significa que, por ejmplo una clase, no debe asumir responsabilidades que deberían pertenecer a otras clases.
-
O - Principio de Abierto/Cerrado (Open/Closed Principle): Las estructuras de control deben estar abiertas para la extensión, pero cerradas para la modificación. Esto significa que el comportamiento de una clase puede extenderse sin modificar su código fuente.
-
L - Principio de Sustitución de Liskov (Liskov Substitution Principle): Las clases derivadas deben ser sustituibles por sus clases base. En otras palabras, si una clase hereda de otra, debe ser posible usar objetos de la clase derivada en lugar de la clase base sin afectar el correcto funcionamiento del programa.
-
I - Principio de Segregación de Interfaces (Interface Segregation Principle): No se debe obligar a una clase a implementar interfaces que no utiliza. Las interfaces más grandes deben descomponerse en interfaces más pequeñas y específicas para que las clases implementen solo las interfaces que necesitan.
-
D - Principio de Inversión de Dependencias (Dependency Inversion Principle): Las clases de alto nivel no deben depender de clases de bajo nivel, sino de abstracciones. De manera similar, las abstracciones no deben depender de detalles, sino que los detalles deben depender de abstracciones. Esto ayuda a reducir la dependencia del código fuente concreto y facilita la escalabilidad y mantenibilidad del software.
¿Qué no son los principios SOLID? Los STUPID principles:
-
S - Singleton: El patŕon Singleton romple con la D de Dependency Inversion Principle por que en cada parte del código donde llamamos de forma estática a una instancia de Singleton estamos creando un fuerte enlace con ella tenemos montado un sistema de caché con Singleton y lo llamamos como
$cache::get('customer_1024'), y quisieramos cambiarlo, tendríamos que a todas las partes de nuestro código donde hacemos uso de esta instancia. En contraposición estaría la inyección por constructor de un sistema de base de datos a través de una interface, esto sería mucho más tolerante al cambio. -
T - Tight Coipling: Código fuertemente acoplado. El código fuertemente acoplado con sistema de pagos por ejemplo, ocasionaría mucho esfuerzo en el caso de que surja la necesidad de cambiar el sistema de pagos. Esto rompería con la I de Interface Segretation Principle, con la D de Dependency Inversion Principle y con la O de Open Closed Principle.
-
U - Untestability: Derivado del hecho de no inyectar las dependencias via constructor, y acoplarnos a ellas creandoo nuevas instancias o llamando a través de metodos estáticos, nos encontramos con una testebilidad muy dificultosa y poco mantenible
-
P - Premature Optimization: La sobreingeniería sin justifación deriva en un aumento de complejidad innecesaria. Añadir capas de complejidad debería ir de la mano de razón para hacerlo
-
I - Indescriptive Naming: Variables, métodos, y clases que por sí solas no son autodesciptivas de su própia funcionalidad, conllevan a un código no legible y lleno de comentarios.
-
D - Duplication: El código duplicado conlleva a que cuando necesiemos cambiar parte del código que esté duplicado, lo tengamos que realizar varias veces. Siempre es aconsejable y muy importante refactorizar, la abstracción de clases con una única resposabilidad y la composición de clases para no tener código duplicado.