No tienes acceso a esta clase

¡Continúa aprendiendo! Únete y comienza a potenciar tu carrera

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

7/27
Recursos

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.

Aportes 6

Preguntas 0

Ordenar por:

¿Quieres ver más aportes, preguntas y respuestas de la comunidad?

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). ```python class Rectangle: def \_\_init\_\_(self, width, height): self.width = width self.height = height def set\_width(self, width): self.width = width def set\_height(self, height): self.height = height def area(self): return self.width \* self.height class Square(Rectangle): def set\_width(self, width): self.width = width self.height = width def set\_height(self, height): self.width = height 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. ```python from abc import ABC, abstractmethod class Shape(ABC): @abstractmethod def area(self): pass class Rectangle(Shape): def \_\_init\_\_(self, width, height): self.width = width self.height = height def set\_width(self, width): self.width = width def set\_height(self, height): self.height = height def area(self): return self.width \* self.height class Square(Shape): def \_\_init\_\_(self, side\_length): self.side\_length = side\_length def set\_side\_length(self, side\_length): self.side\_length = side\_length def area(self): 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: ```python \# 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.
## 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.
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.
me parece a mi o el archivo after y before tienen lo mismo, de la clase anterior
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.
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. ```python 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.