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

Clase 7 de 27 • Curso de Patrones de Diseño y SOLID en Python

Resumen

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

student•

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.

edgardo ponce

student•

me parece a mi o el archivo after y before tienen lo mismo, de la clase anterior

Jovanny Delgado

student•

Principio de Sustitución de Liskov (LSP) en Python

El Principio de Sustitución de Liskov (LSP) es un concepto fundamental en la programación orientada a objetos que establece que:

Si S es un subtipo de T, entonces los objetos de tipo T en un programa pueden ser reemplazados por objetos de tipo S (es decir, objetos de la subclase) sin alterar ninguna de las propiedades deseables del programa (corrección, tarea que realiza, etc.).

En términos más simples, una subclase debe ser totalmente sustituible por su superclase sin que el código que utiliza la superclase se vea afectado.

¿Por qué es importante el LSP en Python?

Mantenibilidad: Al garantizar que las subclases se comporten como se espera, se facilita el mantenimiento y la evolución del código.
Reutilización: Las subclases pueden ser utilizadas en cualquier lugar donde se espera una instancia de la superclase.
Corrección: Evita errores inesperados al garantizar que las subclases no violen el contrato de la superclase.

Wilbertson Mojica Cifuentes

student•

Para implementar el Principio de Sustitución de Liskov (LSP) en Python, puedes usar un ejemplo simple de herencia. Imagina una clase base Animal y dos subclases Perro y Gato. Ambas subclases deben poder ser utilizadas como instancias de Animal sin alterar el comportamiento esperado.

class Animal:
    def hacer_sonido(self):
        raise NotImplementedError("Subclases deben implementar este método")

class Perro(Animal):
    def hacer_sonido(self):
        return "Guau!"

class Gato(Animal):
    def hacer_sonido(self):
        return "Miau!"

def hacer_sonido_animal(animal: Animal):
    print(animal.hacer_sonido())

perro = Perro()
gato = Gato()

hacer_sonido_animal(perro)  # Salida: Guau!
hacer_sonido_animal(gato)   # Salida: Miau!

En este ejemplo, Perro y Gato pueden ser utilizados en lugar de Animal sin causar errores, cumpliendo así con LSP.

Eduardo José Álvarez

Team Platzi•

hola!

Rodrigo Martinez

student•

El principio de sustitución de Liskov dice que si tienes un juguete que funciona con pilas, cualquier juguete diferente que use el mismo tipo de pilas debe funcionar igual. Si cambias el juguete por otro que también usa esas pilas, no debe romperse ni hacer algo inesperado. Así, todos los juguetes que usan las mismas pilas deben ser buenos amigos y funcionar bien juntos. Esto ayuda a que todo funcione como esperamos en nuestros juegos.

Rodrigo Martinez

student•

ELIM5

Kevin Gonzalez

student•

¿Este principio desalienta la sobrecarga de métodos?

Platzi

student•

El principio de sustitución de Liskov no desalienta la sobrecarga de métodos, sino la modificación de la firma de los métodos de la clase base en las subclases.

Fireman Pineda

student•

¿ Las subclases podrían añadir nuevos metodos originales de cada subclase, sin violar el principio de sustitución de liskov ?

Esteban Xavier Moyolema Paz

student•

Considero que hay un error en esta clase. El principio establece que los objetos de la clase base deben poder ser sustituidos por objetos de las subclases, no al revés. "Las subclases deben ser sustituibles por sus clases base" dice en la presentación, lo que es incorrecto: las subclases tienen otros métodos propios, además de los que heredan de la clase base, por lo que es claramente incorrecta esta declaración.

Ronaldo Jiménez

student•

El Principio de Sustitución de Liskov (LSP) establece que las subclases deben ser sustituibles por sus clases base.

Ederson Felipe Lopez Bolivar

student•

realmente no asi como lo mencionas , los objetos "hijos" pueden tener sus propios métodos y aun asi remplazar la clase padre cumpliendo el principio de sustitución de Liskob

Mariano Gobea Alcoba

student•

El Principio de Sustitución de Liskov (LSP) establece que las subclases deben ser sustituibles por sus clases base.

Ejemplo de aplicabilidad: Imagina una clase base Vehículo con un método mover(). Una subclase Coche hereda de Vehículo y también implementa mover(). Si sustituyes un objeto Coche por Vehículo, el comportamiento sigue siendo coherente.

Ejemplo de no aplicabilidad: Supón que tienes una clase base Forma y una subclase Cuadrado que redefine el método area() de forma que se espera un lado, pero cambia la lógica para depender de un atributo que no existe en Forma. Esto viola el LSP, pues al sustituir Forma por Cuadrado, ocurrirán errores inesperados.

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

Patrones de Diseño y Principios SOLID

Patrones de diseño y SOLID en Python

Principios SOLID

Principio de responsabilidad única en SOLID

Refactorizando código Python con principios SOLID

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

Open Closed Principle: extensión sin modificación

Cómo usar clases abstractas en Python