Principios SOLID

English

Son pautas de diseño a nivel de código para escribir software que promueven la modularidad, extensibilidad y mantenibilidad. Aunque son principios a nivel de código, tienen una gran influencia en los principios de los componentes, por lo que sus conceptos también reflejan eso.

Existen 5 principios:

Principios de Responsabilidad Única

Establece que cada clase, módulo o componente de software debe tener una única responsabilidad clara y específica, esto implica que no debe tener dependencias o responsabilidades adicionales que no estén relacionadas con su propósito principal.

Ejemplo Incorrecto	Ejemplo Correcto
La clase Worker define los métodos generateReport() y calculateSalary(), los cuales aportan mas de una responsabilidad y no se relacionan directamente con su propósito principal	Para cumplir este principio, se delegó la responsabilidad a las clases ReportGenerator y CompensationCalculator para tratar esos métodos. Ahora cada clase tiene una única responsabilidad clara y específica.

Principio Abierto - Cerrado

Establece como objetivo la extensión de comportamiento de una manera fácil, sin tener un alto impacto frente al cambio o sin modificar el código existente.

Ejemplo Incorrecto	Ejemplo Correcto
La clase Specification define los atributos y métodos para cada modelo de iPhone. El problema surge si se requieren nuevas especificaciones diferentes a las establecidas, ya que implicaría modificar el código, violando el principio.	Para cumplir este principio, se ha creado la interfaz Model. Luego, cada vez que aparezca un nuevo modelo, solo debe implementar de la interfaz Model, como se observa en los modelos Plus y Pro.

Principio de Sustitución de Liskov

El objetivo del principio es asegurar que una subclase pueda usarse como su superclase sin generar efectos indeseables o errores en el comportamiento del programa en su conjunto.

Ejemplo Incorrecto	Ejemplo Correcto
Disponemos de la representación de aves y sus métodos más comunes. El comportamiento del método fly() es esperado en las aves como Paloma y Cuervo, pero es inesperado en el caso del Pingüino, ya que no debería tener implementado dicho método. Esto incumple el principio, ya que la subclase (Pingüino) no se puede usar como su superclase (Ave).	Para cumplir este principio, se ha añadido la interface FlyingBird que contiene el método fly() y ahora solo las aves que posean la capacidad de volar implementarían esta interface, por otro lado, la clase Pingüino solo implementaría de Ave

Principio de Segregación de Interfaces

Este principio establece que las interfaces deben ser específicas y coherentes para cada cliente, evitando la inclusión de funcionalidades innecesarias o confusas.

Ejemplo Incorrecto	Ejemplo Correcto
Tenemos la interface Repository y dos clases que la implementan; sin embargo, el método getRemoteItems() no se usa en LocalRepository y el método getLocalItems() no se usa en RemoteRepository. Esto indica un incumplimiento de este principio.	Para cumplir este principio, es necesario crear otra interface para dividir mejor las funcionalidades para cada implementación. Ahora tenemos la interface LocalRepository y RemoteRepository, junto con sus respectivas implementaciones, donde los métodos son específicos y coherentes.

Principio de Inversión de Dependencias

Este principio establece que las políticas de alto nivel no deben depender directamente de los detalles de bajo nivel, sino de abstracciones.

Ejemplo Incorrecto	Ejemplo Correcto
El caso de uso llama directamente a CustomRemoteRepository, lo cual implica que está consciente de los detalles de implementación de dicha clase, como el uso de frameworks o librerías para llevar a cabo sus funciones. Esto viola el principio mencionado.	Para cumplir este principio, usamos una interface RemoteRepository como abstracción para evitar depender de los detalles específicos de implementación. Ahora son los detalles, como CustomRemoteRepository, los que dependen de la política de alto nivel.