Principio de sustitución de Liskov en Python

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:006:38

Principio de sustitución de Liskov en Python

Curso de Patrones de Diseño y SOLID en Python

Clase 8 de 27

Clase 8 / 27

Recursos

Aprende a aplicar el principio de sustitución de Liskov (LSP) en Python usando protocolos, detectando y corrigiendo un bug real en un notificador por SMS. Verás cómo usar docstrings en formato NumPy, aprovechar un default factory y garantizar que las clases sean intercambiables sin romper el servicio de pagos.

¿Qué problema rompe el principio de sustitución de Liskov?

En el proyecto se reemplazaron las clases abstractas por protocolos (interfaces en Python) para Notifier y Payment Processor. Se añadieron docstrings que documentan comportamiento, parámetros y tipos, usando el formato NumPy en send_confirmation y describiendo también process_transaction.

Se introdujo a propósito un bug para ilustrar LSP: EmailNotifier respeta la firma del método send_confirmation(customer_data), tal como exige el protocolo, pero SMSNotifier exige un parámetro adicional sms_gateway. Al inyectar SMSNotifier en el servicio de pagos —que por defecto notifica por email mediante un default factory—, el debugger mostró: validación de cliente y pago correctas, cargo en Stripe correcto, pero una excepción al ejecutar SMSNotifier por incompatibilidad de firma. Esto impide sustituir email por SMS sin cambios en el servicio, violando LSP.

Protocolos: forma de declarar interfaces en Python con comportamiento similar a clases abstractas.
Docstrings: documentación del comportamiento y tipos; se usó formato NumPy.
Firma del método: el protocolo define send_confirmation(customer_data).
Bug: SMSNotifier pedía sms_gateway como parámetro y rompía la sustitución.

¿Cómo se veía la firma incompatible?

from typing import Protocol

class Notifier(Protocol):
    def send_confirmation(self, customer_data):
        ...

class EmailNotifier:
    def send_confirmation(self, customer_data):
        """
        Parameters
        ----------
        customer_data : dict
            Datos del cliente para confirmar la transacción.
        """
        pass

class SMSNotifier:
    # Incumple el protocolo: agrega un parámetro extra.
    def send_confirmation(self, customer_data, sms_gateway):  # rompe LSP
        pass

¿Cómo se corrige con dataclass y atributos?

La solución fue convertir SMSNotifier en data class y mover sms_gateway a un atributo de instancia. Así, el método respeta la firma del protocolo y usa el atributo interno.

from dataclasses import dataclass

@dataclass
class SMSNotifier:
    sms_gateway: str  # Atributo en lugar de parámetro del método.

    def send_confirmation(self, customer_data):
        # Aquí se usaría self.sms_gateway para enviar el SMS.
        pass

# Instanciación correcta del notificador SMS.
sms_notifier = SMSNotifier(sms_gateway="this is a SMS mock get")

Con este ajuste, EmailNotifier y SMSNotifier comparten la misma firma y son sustituibles.

¿Cómo se prueba la sustitución en el servicio de pagos?

En la implementación del servicio se creó un notificador por SMS y otro por email. El servicio de pagos, por defecto, usa el notificador de email gracias al default factory, pero se puede pasar el notificador SMS por parámetro. Con un breakpoint en la sección clave y usando el debugger se verificó: validación de cliente y pago correctas, cargo en Stripe, y tras la corrección, no se generó ninguna excepción. Luego se probó cambiando al notificador por email y todo funcionó de forma intercambiable, sin modificar el servicio.

¿Qué habilidades y conceptos se refuerzan?

Principio de sustitución de Liskov: clases hijas o implementaciones deben ser intercambiables sin romper el cliente.
Protocolos en Python: alternativa ligera a clases abstractas para definir interfaces.
Docstrings en formato NumPy: claridad en comportamiento, parámetros y tipos.
Firma consistente: evitar parámetros extra que rompen la interfaz.
Data class: mover dependencias a atributos de instancia.
Instanciación correcta: pasar el sms_gateway al crear SMSNotifier.
Pruebas con debugger y breakpoint: validar flujo y detectar excepciones.
Configuración por defecto con default factory: email como estrategia de notificación base.

¿Qué errores detectarías y cómo mejorarlos?

Verifica que todas las implementaciones de Notifier respeten la misma firma.
Asegura que los servicios acepten cualquier notificador sin cambios internos.
Documenta con docstrings los tipos esperados y valores de retorno.
Repite la prueba con ambos notificadores para confirmar la intercambiabilidad.

¿De qué otra forma aplicarías Liskov aquí? ¿Qué otros detalles mejorarías en el código? Comparte tu enfoque en los comentarios.

Mario Alexander Vargas Celis

Hace 2 años

Para aplicar el **Principio de Sustitución de Liskov** (LSP), las subclases deben comportarse de manera que puedan sustituir a su clase base sin alterar el funcionamiento del sistema. Esto implica que la subclase debe cumplir con el contrato de la clase base en cuanto a comportamiento, sin añadir restricciones o modificar expectativas fundamentales.

### Ejemplo: Aplicación Correcta del LSP en Python

Imaginemos que estamos desarrollando un sistema para un zoológico que maneja diferentes tipos de aves. Tenemos una clase Bird que representa un ave general con un método fly. Queremos agregar subclases Eagle (que puede volar) y Penguin (que no vuela).

#### Ejemplo Incorrecto: Violación del LSP

En este caso, al intentar hacer que Penguin herede de Bird pero no pueda volar, estamos violando el LSP, ya que Penguin no cumple con el comportamiento esperado (poder volar) de Bird.


class Bird:

&#x20;   def fly(self):

&#x20;       print("I can fly!")



class Eagle(Bird):

&#x20;   pass



class Penguin(Bird):

&#x20;   def fly(self):

&#x20;       raise Exception("I can't fly!")

Con este diseño, Penguin no se comporta como un Bird común, ya que lanza una excepción en lugar de volar, lo cual rompe el LSP. Si un programa intenta llamar al método fly en una instancia de Penguin y espera que funcione igual que en Bird, se generará un error inesperado.

### Solución: Aplicando el LSP

Para cumplir con el LSP, podemos rediseñar la estructura usando una clase base Bird con dos subclases específicas: FlyingBird y NonFlyingBird. Esto nos permite representar correctamente tanto a las aves que vuelan como a las que no, sin que una interfiera en la funcionalidad de la otra.


from abc import ABC, abstractmethod



\# Clase base abstracta

class Bird(ABC):

&#x20;   @abstractmethod

&#x20;   def make\_sound(self):

&#x20;       pass



\# Subclase para aves que pueden volar

class FlyingBird(Bird):

&#x20;   def fly(self):

&#x20;       print("I can fly!")



\# Subclase para aves que no vuelan

class NonFlyingBird(Bird):

&#x20;   def fly(self):

&#x20;       raise NotImplementedError("This bird can't fly.")



\# Aves específicas

class Eagle(FlyingBird):

&#x20;   def make\_sound(self):

&#x20;       print("Screech!")



class Penguin(NonFlyingBird):

&#x20;   def make\_sound(self):

&#x20;       print("Honk!")

### Explicación

- **Clase Bird**: Es una clase base abstracta que define el método make\_sound que todas las aves deben implementar.

- **Clases FlyingBird y NonFlyingBird**: Son clases intermedias que especifican si un ave puede volar o no. FlyingBird implementa el método fly, mientras que NonFlyingBird levanta una excepción controlada con NotImplementedError para indicar que estas aves no vuelan.

- **Clases Eagle y Penguin**: Estas representan tipos específicos de aves que implementan el método make\_sound de la clase base Bird. Eagle puede volar gracias a que hereda de FlyingBird, y Penguin no vuela porque hereda de NonFlyingBird.

### Uso del Código

Podemos crear instancias de Eagle y Penguin y usarlas de manera segura sin que una viole el comportamiento esperado de la otra.


\# Crear instancias

eagle = Eagle()

penguin = Penguin()



\# Ejecutar métodos

eagle.make\_sound()    # Screech!

eagle.fly()           # I can fly!



penguin.make\_sound()  # Honk!

\# penguin.fly()        # Esto lanza NotImplementedError, lo cual es el comportamiento esperado

### Ventajas de Aplicar el LSP

1. **Consistencia en el Comportamiento**: Las subclases cumplen con el comportamiento esperado sin generar resultados inesperados o excepciones imprevistas.

2. **Reusabilidad**: Las clases FlyingBird y NonFlyingBird actúan como plantillas reutilizables para cualquier tipo de ave que vuele o no vuele, respectivamente.

3. **Mantenibilidad**: Se puede extender la jerarquía con nuevas clases de aves sin tener que modificar la lógica existente.

### Conclusión

El Principio de Sustitución de Liskov nos ayuda a crear una jerarquía de clases que se comporta de manera predecible, cumpliendo con las expectativas del usuario de la clase base. En este ejemplo, hemos creado un diseño que permite agregar nuevos tipos de aves sin romper la funcionalidad de las existentes, cumpliendo así con el LSP y mejorando la estabilidad y extensibilidad del sistema.

Comentarios (13)13 comentarios

Mariano Gobea Alcoba

Wilbertson Mojica Cifuentes

Franco Coloccini

German Prieto

Bryann Andrei Valderrama Avila

Frandy De La Cruz

Hace 2 meses

Platzi

Victor Pinto

jorge alarcon

Hace 10 meses•editado

Minería Datos

Hace un año

Cesar Augusto Mora Castilo

Juan Camilo Suarez

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 sustitución de Liskov en Python

Progreso del curso

Patrones de Diseño y Principios SOLID

Principios SOLID

Reestructuración del proyecto

Patrones de Diseño

Recursos

Recursos