Principio de Liskov en S.O.L.I.D.

Curso de Patrones de Diseño y SOLID en Python

Contenido del curso

Patrones de Diseño y Principios SOLID

1
Patrones de diseño y SOLID en Python
02:07 min

Principios SOLID

Reestructuración del proyecto

13
Reestructuración con módulos de Python y SOLID
13:32 min

Patrones de Diseño

Tomar examen

Cursos Empresas Blog Live Conf Eventos Precios

0:003:18

Principio de Liskov en S.O.L.I.D.

Curso de Patrones de Diseño y SOLID en Python

Clase 7 de 27

Clase 7 / 27

Recursos

Comprende y aplica con seguridad la L de S.O.L.I.D.: el principio de sustitución de Liskov garantiza coherencia, interoperabilidad y evita comportamientos inesperados. Propuesto por Barbara Liskov, establece una regla simple y poderosa: las subclases deben poder usarse en lugar de su clase base sin romper nada.

¿Qué es el principio de sustitución de Liskov y por qué importa?

El Liskov Substitution Principle define que las subclases deben ser sustituibles por sus clases base. Esto asegura que el sistema mantenga su consistencia y la correcta ejecución del programa al intercambiar implementaciones que comparten contrato y comportamiento.

En palabras simples:

Las subclases respetan el contrato de la clase base.
No cambian la firma de los métodos ni el tipo de retorno.
No requieren atributos nuevos para poder usar los métodos existentes.
Mantienen compatibilidad de interfaces y tipos.
No introducen excepciones inesperadas ni parámetros adicionales que rompan llamadas existentes.

¿Cómo se aplica en diseño de clases e interfaces?

Para que distintas implementaciones sean interoperables, quienes heredan de una clase o implementan una interfaz deben poder usarse de la misma forma que el original. Así se promueve la reutilización del código en múltiples contextos, sin cambios de última hora.

¿Qué significa respetar el contrato?

Mantener firma de métodos: mismos parámetros y orden.
Mantener el tipo de retorno acordado.
Conservar las reglas de uso: precondiciones y postcondiciones.
Evitar agregar requisitos nuevos para invocar un método.

¿Qué errores se evitan?

Cambios que exijan un parámetro extra o de otro tipo.
Retornos con tipos distintos a los esperados.
Excepciones inesperadas al usar una subclase en lugar de la clase base.

Estas prácticas fortalecen habilidades como el diseño de contratos claros, el control de precondiciones/postcondiciones y la gestión de tipos y excepciones en jerarquías de clases.

¿Cuándo detectarlo y qué beneficios ofrece?

Cuando hay violaciones del principio, aparecen señales claras:

Violación de precondiciones o postcondiciones: cambia cómo se invocan los métodos.
Parámetros adicionales o de otro tipo en subclases.
Tipo de retorno modificado respecto a la clase base.
Excepciones inesperadas en subclases al usarlas como la clase original.

Si notas estos síntomas, hay inconsistencia con el principio de sustitución de Liskov y la sustitución deja de ser fácil.

Beneficios de aplicarlo bien:

Reutilización del código en distintos contextos, sin tocar llamadas existentes.
Compatibilidad de interfaces y tipos a lo largo del sistema.
Menos errores en tiempo de ejecución por evitar situaciones inesperadas.
Coherencia entre componentes que comparten una misma interfaz o clase base.

¿Cómo lo aplicarías al proyecto del procesador de pagos? Comparte tu enfoque y ejemplos en los comentarios.

Mario Alexander Vargas Celis

Hace 2 años

El **Principio de Sustitución de Liskov** (Liskov Substitution Principle, LSP) establece que **los objetos de una clase derivada deben poder ser sustituidos por objetos de la clase base** sin alterar la funcionalidad del programa. En otras palabras, las clases derivadas deben comportarse de manera consistente con las expectativas establecidas por la clase base, asegurando que el código que usa la clase base funcione correctamente con cualquiera de sus subclases.

### Ejemplo de Código que Viola el LSP

Supongamos que estamos modelando una jerarquía de clases para figuras geométricas. Definimos una clase base Rectangle y una clase derivada Square que hereda de Rectangle. Aunque un cuadrado puede considerarse un tipo especial de rectángulo, esta relación viola el principio LSP porque el cuadrado no se comporta como un rectángulo en el sentido general (al cambiar su ancho o alto, ambos deben cambiar, ya que los lados de un cuadrado siempre son iguales).


class Rectangle:

&#x20;   def \_\_init\_\_(self, width, height):

&#x20;       self.width = width

&#x20;       self.height = height



&#x20;   def set\_width(self, width):

&#x20;       self.width = width



&#x20;   def set\_height(self, height):

&#x20;       self.height = height



&#x20;   def area(self):

&#x20;       return self.width \* self.height



class Square(Rectangle):

&#x20;   def set\_width(self, width):

&#x20;       self.width = width

&#x20;       self.height = width



&#x20;   def set\_height(self, height):

&#x20;       self.width = height

&#x20;       self.height = height

### Problema

Esta jerarquía viola el LSP. Si sustituimos un Rectangle por un Square, se puede producir un comportamiento inesperado. Por ejemplo, si intentamos cambiar solo el ancho del Square, también cambia la altura, lo cual no se esperaría en un Rectangle.

### Solución: Aplicando el LSP

Para cumplir con el LSP, debemos rediseñar la jerarquía. En lugar de hacer que Square herede de Rectangle, podemos crear una clase base Shape que define una interfaz común para las figuras geométricas, de manera que Rectangle y Square sean clases independientes que implementan esa interfaz.


from abc import ABC, abstractmethod



class Shape(ABC):

&#x20;   @abstractmethod

&#x20;   def area(self):

&#x20;       pass



class Rectangle(Shape):

&#x20;   def \_\_init\_\_(self, width, height):

&#x20;       self.width = width

&#x20;       self.height = height



&#x20;   def set\_width(self, width):

&#x20;       self.width = width



&#x20;   def set\_height(self, height):

&#x20;       self.height = height



&#x20;   def area(self):

&#x20;       return self.width \* self.height



class Square(Shape):

&#x20;   def \_\_init\_\_(self, side\_length):

&#x20;       self.side\_length = side\_length



&#x20;   def set\_side\_length(self, side\_length):

&#x20;       self.side\_length = side\_length



&#x20;   def area(self):

&#x20;       return self.side\_length \* self.side\_length

### Explicación

- **Clase Shape**: Es una clase abstracta que define un método area, el cual debe ser implementado por cualquier figura geométrica.

- **Clase Rectangle**: Implementa Shape y mantiene su propio ancho y alto.

- **Clase Square**: Implementa Shape y tiene solo un atributo side\_length, lo cual hace que se comporte como un cuadrado.

### Uso del Código

Ahora, Rectangle y Square son clases independientes que se pueden usar sin que una dependa de la otra, cumpliendo así con el LSP:


\# Crear instancias de Rectangle y Square

rectangle = Rectangle(5, 10)

square = Square(7)



\# Calcular áreas

print(f"Área del rectángulo: {rectangle.area()}")

print(f"Área del cuadrado: {square.area()}")

### Ventajas de Aplicar el LSP

1. **Consistencia en el Comportamiento**: Cada clase respeta las expectativas de su clase base o interfaz, evitando resultados inesperados.

2. **Simplicidad**: No se generan interdependencias confusas entre clases que comparten ciertos atributos pero se comportan de manera distinta.

3. **Extensibilidad**: Podemos agregar nuevas formas geométricas simplemente implementando la clase base Shape, sin afectar el comportamiento de Rectangle o Square.

### Conclusión

Aplicar el **Principio de Sustitución de Liskov** garantiza que las subclases se comporten de manera consistente con la clase base, lo que permite que el código sea más predecible y libre de errores. En este ejemplo, el rediseño asegura que Square y Rectangle puedan ser usados en un contexto común (el de una Shape) sin crear dependencias innecesarias ni violar las expectativas del comportamiento de cada clase.

Patrones de Diseño y Principios SOLID

Patrones de diseño y SOLID en Python

Principios SOLID

Qué es el principio de responsabilidad única

Procesador de pagos en Python con Stripe

Cómo aplicar SRP en un procesador de pagos con Stripe

Principio open-closed en Python

Clases abstractas y principio abierto-cerrado

Principio de Liskov en S.O.L.I.D.

Principio de sustitución de Liskov en Python

Principio de segregación de interfaces en SOLID

Segregación de interfaces en procesadores de pagos

Principio de inversión de dependencias en SOLID

Principio de inversión de dependencias: servicio de pagos flexible

Reestructuración del proyecto

Reestructuración con módulos de Python y SOLID

Patrones de Diseño

Qué son los patrones de diseño: definición y categorías

Strategy Pattern con Python y setprocessor

Strategy Pattern para pagos en Python

Factory Pattern: centralizar creación de objetos

Patrón Factory para procesar pagos con match

Qué es el patrón Decorator

Patrón decorador en servicios de pagos

Builder Pattern: construcción paso a paso

Builder Pattern aplicado a un servicio de pagos

Observer Pattern en sistemas de eventos

Observer en sistemas de pagos con Python

Chain of Responsibility para validar pagos

Chain of Responsibility en servicios de pagos

Código funcional vs código mantenible en Python

Principio de Liskov en S.O.L.I.D.

Progreso del curso

Patrones de Diseño y Principios SOLID

Principios SOLID

Reestructuración del proyecto

Patrones de Diseño

Recursos

Recursos