Principio de Sustitución de Liskov en Desarrollo de Software

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

Resumen

El principio de sustitución de Liskov (LSP) es clave para garantizar la coherencia y la interoperabilidad en sistemas orientados a objetos. Propone que las subclases deben ser intercambiables con sus clases base sin alterar el comportamiento esperado. Esto evita problemas inesperados y asegura que las clases que implementen una interfaz o hereden de otra puedan utilizarse de manera consistente, facilitando la reutilización del código y reduciendo errores en tiempo de ejecución.

¿Qué establece el principio de sustitución de Liskov?

Este principio, propuesto por Barbara Liskov, establece que las subclases deben ser sustituibles por sus clases base sin afectar el comportamiento del programa. Es esencial para asegurar que el sistema se mantenga coherente y funcione correctamente cuando se emplean clases derivadas.

¿Cómo se aplican las subclases en LSP?

Las subclases deben respetar el contrato de la clase base. Esto significa que:

No se puede cambiar la firma de los métodos.
No se deben agregar nuevos atributos que afecten la funcionalidad de los métodos existentes.
La interfaz y los tipos deben mantenerse compatibles.

¿Qué errores evita el principio de sustitución?

El LSP ayuda a evitar errores como:

Excepciones inesperadas cuando se requieren parámetros adicionales no previstos en la clase base.
Cambios en el tipo de retorno de los métodos que interrumpen la compatibilidad entre clases.

¿Cuáles son los beneficios del principio de sustitución?

Reutilización del código: Las clases que cumplen con LSP pueden ser utilizadas en diferentes contextos sin modificaciones.
Compatibilidad de interfaces: Facilita que las clases puedan interactuar de forma coherente sin errores inesperados.
Reducción de errores en tiempo de ejecución: El código se mantiene predecible y coherente, disminuyendo la posibilidad de fallos imprevistos.

¿Cuándo aplicar el principio de sustitución de Liskov?

Es necesario aplicarlo cuando:

Hay violación de precondiciones o poscondiciones, es decir, cuando los parámetros o el tipo de retorno de los métodos cambian.
Se presentan excepciones inesperadas al usar subclases, lo que indica que no se puede hacer una sustitución sencilla entre ellas.

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.