¿Por qué es importante?

• Mayor mantenibilidad: Cuando una clase tiene una sola responsabilidad, es más fácil de entender y modificar. Si necesitas cambiar algo, sabrás exactamente dónde buscar.

• Menor acoplamiento: Al separar las responsabilidades en diferentes clases, reduces el acoplamiento entre ellas. Esto significa que los cambios en una clase tienen menos impacto en otras partes del sistema.

• Facilidad de prueba: Las clases con una sola responsabilidad son más fáciles de probar de forma aislada.

• Reutilización de código: Classes con responsabilidades bien definidas son más fáciles de reutilizar en diferentes partes de una aplicación.

  
  

  Ejemplo:

  Imagina una clase llamada Usuario. Si esta clase se encarga de gestionar los datos del usuario, su autenticación y enviar correos electrónicos, está violando el SRP. Tendríamos que cambiar esta clase cada vez que queramos modificar cualquier aspecto de estas responsabilidades.

  Una mejor solución sería crear tres clases diferentes:

  • Usuario: Se encarga de almacenar los datos del usuario.

  • Autenticacion: Se encarga de autenticar al usuario.

  • CorreoElectronico: Se encarga de enviar correos electrónicos.

  Cada clase tiene una única responsabilidad, lo que hace el código más limpio y mantenible.

¿Por qué es importante?

• Mantenibilidad: Al evitar modificar el código existente, reduces el riesgo de introducir nuevos errores.

• Estabilidad: Un sistema que cumple con el OCP es más estable, ya que los cambios se realizan agregando nuevas funcionalidades en lugar de modificar las existentes.

• Reusabilidad: Las clases diseñadas siguiendo el OCP son más fáciles de reutilizar en diferentes contextos.

• Facilidad de prueba: Al no modificar el código existente, es más sencillo escribir pruebas unitarias y mantenerlas actualizadas.

Ejemplo:

Imagina que tienes una aplicación de figuras geométricas. Inicialmente, solo tienes clases para calcular el área de círculos y cuadrados. Más adelante, necesitas calcular el área de triángulos. Si no aplicas el OCP, tendrías que modificar la clase que calcula el área, añadiendo una nueva condición para los triángulos.

Aplicando el OCP, crearías una interfaz FiguraGeometrica con un método calcularArea(). Luego, crearías clases Circulo, Cuadrado y Triangulo que implementen esta interfaz. Al agregar una nueva figura, solo tendrías que crear una nueva clase que implemente la interfaz, sin modificar las clases existentes.

¿Por qué es importante?

• Mantiene la jerarquía de clases: El LSP garantiza que la relación "es un" entre una clase base y una subclase se mantenga.

• Facilita la reutilización de código: Si una subclase puede reemplazar a su clase base, puedes escribir código más genérico que funcione con cualquier objeto de la jerarquía.

• Mejora la mantenibilidad: Al asegurar que las subclases no rompen el contrato de la clase base, se reduce la probabilidad de introducir errores al modificar el código.

¿Cuándo se viola el LSP?

• Contrato roto: Cuando una subclase modifica el comportamiento de un método heredado de manera que no es compatible con el contrato de la clase base.

• Precondiciones más fuertes: Si una subclase impone restricciones más fuertes en los parámetros de un método que la clase base.

• Postcondiciones más débiles: Si una subclase devuelve un resultado menos preciso o menos completo que el prometido por la clase base.

• Excepciones adicionales: Si una subclase lanza excepciones que no son esperadas por la clase base.

Ejemplo:

Imagina una jerarquía de clases con una clase base Rectangulo y subclases Cuadrado y RectanguloEscaleno. Si intentas hacer que Cuadrado herede de Rectangulo y luego cambias el tamaño de un cuadrado, estarías violando el LSP, ya que cambiar la altura de un cuadrado también cambia su ancho, lo cual no es válido para un rectángulo en general.

¿Por qué es importante?

• Acoplamiento reducido: Al dividir una interfaz grande en varias más pequeñas, se reduce el acoplamiento entre las clases que implementan esas interfaces. Esto significa que los cambios en una interfaz tienen un impacto menor en otras partes del sistema.

• Mayor cohesión: Cada interfaz se enfoca en un conjunto específico de responsabilidades, lo que aumenta la cohesión interna de las clases que la implementan.

• Flexibilidad: Al permitir que las clases implementen solo las interfaces que necesitan, se aumenta la flexibilidad del sistema.

• Mejor mantenibilidad: Un sistema con interfaces más pequeñas es más fácil de entender y mantener.

¿Cuándo se viola el ISP?

• Interfaces "gordas": Cuando una interfaz contiene muchos métodos que no son necesarios para todos los clientes que la implementan.

• Clases que implementan métodos innecesarios: Cuando una clase se ve obligada a implementar métodos de una interfaz que no utiliza.

Ejemplo:

Imagina una aplicación que gestiona diferentes tipos de impresoras. Podríamos tener una interfaz Impresora con métodos como imprimirDocumento, imprimirImagen y escanearDocumento. Sin embargo, no todas las impresoras pueden escanear. Al obligar a todas las clases que implementan Impresora a implementar el método escanearDocumento, estaríamos violando el ISP.

Una mejor solución sería crear dos interfaces: Impresora (con los métodos imprimirDocumento e imprimirImagen) y Escáner (con el método escanearDocumento). Las impresoras que pueden escanear implementarían ambas interfaces.

• Las clases de alto nivel no deben depender de las clases de bajo nivel. Ambas deberían depender de abstracciones (como interfaces).

• Las abstracciones no deben depender de los detalles. Los detalles (implementaciones concretas) deben depender de las abstracciones.

En términos más simples, esto significa que las clases no deben estar acopladas directamente a implementaciones concretas, sino a interfaces o clases abstractas.

¿Por qué es importante?

• Desacoplamiento: Reduce la dependencia entre módulos, haciendo el sistema más flexible y fácil de cambiar.

• Reusabilidad: Al depender de abstracciones, las clases se vuelven más reutilizables en diferentes contextos.

• Testabilidad: Es más fácil crear pruebas unitarias al aislar las clases de sus dependencias concretas.

• Mantenibilidad: Los cambios en las implementaciones concretas tienen un menor impacto en el resto del sistema.

¿Cómo se aplica el DIP?

• Interfaces: Define interfaces para representar las abstracciones.

• Inyección de dependencias: En lugar de instanciar directamente las clases de bajo nivel, estas se inyectan en las clases de alto nivel a través del constructor o propiedades.

• Contenedores de inversión de control (IoC): Herramientas que automatizan la gestión de las dependencias y la inyección de las mismas.

Ejemplo

Imagina una aplicación que envía notificaciones por correo electrónico. Sin aplicar el DIP, una clase Notificador podría depender directamente de una clase ServicioCorreoElectronico. Si quisiéramos cambiar el proveedor de correo electrónico, tendríamos que modificar la clase Notificador.

Aplicando el DIP, crearíamos una interfaz IServicioCorreoElectronico y la clase Notificador dependería de esta interfaz. Luego, en el momento de ejecutar la aplicación, se inyectaría una implementación concreta del servicio de correo electrónico (por ejemplo, Gmail, Outlook).