Principio de sustitución de Liskov en Python

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

Resumen

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.

Mariano Gobea Alcoba

student•

Hacía rato que no venía por los pagos de Platzi a hacer cursos!

Da placer ver cursos de esta calidad en el producto!

Mis sinceras felicitaciones a todo el Platzi Team!

Wilbertson Mojica Cifuentes

student•

El siguiente es un ejemplo sencillo en Python que muestra la implementación de interfaces utilizando Protocol:

from typing import Protocol

class Notifier(Protocol):
    def send_notification(self, message: str) -> None:
        ...

class EmailNotifier:
    def send_notification(self, message: str) -> None:
        print(f"Enviando correo: {message}")

class SMSNotifier:
    def send_notification(self, message: str) -> None:
        print(f"Enviando SMS: {message}")

def notify(notifier: Notifier, message: str) -> None:
    notifier.send_notification(message)

email_notifier = EmailNotifier()
sms_notifier = SMSNotifier()

notify(email_notifier, "Hola a todos!")
notify(sms_notifier, "Hola a todos!")

En este ejemplo, Notifier es un protocolo que define un método send_notification. Tanto EmailNotifier como SMSNotifier implementan este método, permitiendo usar cualquiera de los dos como notificadores.

Franco Coloccini

student•

Hola! En ese código te faltaría que las clases EmailNotifier y SMSNotifier hereden del protocolo Notifier, para que puedan ser pasadas como parámetros en el método notify(), ya que exige su primer parámetro como tipo Notifier.

Quedaría: class EmailNotifier(Notifier): class SMSNotifier(Notifier):

German Prieto

student•

Buen punto ... no es necesario que EmailNotifier y SMSNotifier hereden de Notifier. Es decir que no requiere una relación explícita.

La función notify recibe como parámetro un Protocol, el cuál se puede substituir por todas las clases que cumplan con el contrato, es decir que tengan la implementación correcta de las funciones de la interfaz.

Franco Coloccini

student•

Al invocar el método process_transaction() de payment_service_sms_notifier lo hace con el parámetro customer_data_with_email y al invocar el de payment_service ingresa el parámetro customer_data_with_phone.

No debería ser al revés?

Debería fallar al tratar de buscar los atributos inexistente.

German Prieto

student•

Tal cual ... funciona por que lo coloca como None (El email o el SMS)

Bryann Andrei Valderrama Avila

student•

El formato de los Docstring no es Numpy, sino Sphinx.

Bryann Andrei Valderrama Avila

student•

Y los pueden generar automáticamente usando la extensión autoDocstring de VSCode.

jorge alarcon

student••

profe una pregunta si implemento asi es lo mismo?

class EmailNotifier:
    def send_confirmation(self, customer_data: CustomerData):
        ...

@dataclass
class SMSNotifier:
    sms_gateway: str

    def send_confirmation(self, customer_data: CustomerData):
        ...

Minería Datos

student•

Una manera en la podria implentar el princio de liskov seria implemnetar el metodo de notificacion con llamada, con la data class, CallNotifier. Me gustaria recibir feedback. Asi esta mi codigo:

import os
from dataclasses import dataclass, field
from typing import Optional, Protocol

import stripe
from dotenv import load_dotenv
from pydantic import BaseModel
from stripe import Charge
from stripe.error import StripeError

_ = load_dotenv()


class ContactInfo(BaseModel):
    email: Optional[str] = None
    phone: Optional[str] = None


class CustomerData(BaseModel):
    name: str
    contact_info: ContactInfo


class PaymentData(BaseModel):
    amount: int
    source: str


@dataclass
class CustomerValidator:
    def validate(self, customer_data: CustomerData):
        if not customer_data.name:
            print("Invalid customer data: missing name")
            raise ValueError("Invalid customer data: missing name")
        if not customer_data.contact_info:
            print("Invalid customer data: missing contact info")
            raise ValueError("Invalid customer data: missing contact info")
        if not (customer_data.contact_info.email or customer_data.contact_info.phone):
            print("Invalid customer data: missing email and phone")
            raise ValueError("Invalid customer data: missing email and phone")


@dataclass
class PaymentDataValidator:
    def validate(self, payment_data: PaymentData):
        if not payment_data.source:
            print("Invalid payment data: missing source")
            raise ValueError("Invalid payment data: missing source")
        if payment_data.amount <= 0:
            print("Invalid payment data: amount must be positive")
            raise ValueError("Invalid payment data: amount must be positive")


class Notifier(Protocol):
    """
    Protocol for sending notifications.

    This protocol defines the interface for notifiers. Implementations
    should provide a method `send_confirmation` that sends a confirmation
    to the customer.
    """

    def send_confirmation(self, customer_data: CustomerData):
        """Send a confirmation notification to the customer.

        :param customer_data: Data about the customer to notify.
        :type customer_data: CustomerData
        """
        ...


class EmailNotifier(Notifier):
    def send_confirmation(self, customer_data: CustomerData):
        from email.mime.text import MIMEText

        msg = MIMEText("Thank you for your payment.")
        msg["Subject"] = "Payment Confirmation"
        msg["From"] = "no-reply@example.com"
        msg["To"] = customer_data.contact_info.email or ""

        print("Email sent to", customer_data.contact_info.email)


@dataclass
class SMSNotifier(Notifier):
    sms_gateway: str

    def send_confirmation(self, customer_data: CustomerData):
        phone_number = customer_data.contact_info.phone
        print(
            f"send the sms using {self.sms_gateway}: SMS sent to {phone_number}: Thank you for your payment."
        )

@dataclass
class CallNotifier(Notifier):
    call_gateway: str

    def send_confirmation(self, customer_data: CustomerData):
        phone_number = customer_data.contact_info.phone
        print(
            f"send the call using {self.call_gateway}: Call made to {phone_number}: Thank you for your payment."
        )

@dataclass
class TransactionLogger:
    def log(
        self, customer_data: CustomerData, payment_data: PaymentData, charge: Charge
    ):
        with open("transactions.log", "a") as log_file:
            log_file.write(f"{customer_data.name} paid {payment_data.amount}\n")
            log_file.write(f"Payment status: {charge['status']}\n")


class PaymentProcessor(Protocol):
    """
    Protocol for processing payments.

    This protocol defines the interface for payment processors. Implementations
    should provide a method `process_transaction` that takes customer data and payment data,
    and returns a Stripe Charge object.
    """

    def process_transaction(
        self, customer_data: CustomerData, payment_data: PaymentData
    ) -> Charge:
        """Process a payment.

        :param customer_data: Data about the customer making the payment.
        :type customer_data: CustomerData
        :param payment_data: Data about the payment to process.
        :type payment_data: PaymentData
        :return: A Stripe Charge object representing the processed payment.
        :rtype: Charge
        """
        ...


@dataclass
class StripePaymentProcessor(PaymentProcessor):
    def process_transaction(
        self, customer_data: CustomerData, payment_data: PaymentData
    ) -> Charge:
        stripe.api_key = os.getenv("STRIPE_API_KEY")
        try:
            charge = stripe.Charge.create(
                amount=payment_data.amount,
                currency="usd",
                source=payment_data.source,
                description="Charge for " + customer_data.name,
            )
            print("Payment successful")
            return charge
        except StripeError as e:
            print("Payment failed:", e)
            raise e


@dataclass
class PaymentService:
    customer_validator = CustomerValidator()
    payment_validator = PaymentDataValidator()
    payment_processor: PaymentProcessor = field(default_factory=StripePaymentProcessor)
    notifier: Notifier = field(default_factory=CallNotifier)
    logger = TransactionLogger()

    def process_transaction(self, customer_data, payment_data) -> Charge:
        self.customer_validator.validate(customer_data)
        self.payment_validator.validate(payment_data)

        try:
            charge = self.payment_processor.process_transaction(
                customer_data, payment_data
            )
        except StripeError as e:
            raise e

        self.notifier.send_confirmation(customer_data)
        self.logger.log(customer_data, payment_data, charge)
        return charge


if __name__ == "__main__":
    sms_notifier = SMSNotifier(sms_gateway="This is a sms mock gateway")
    payment_service = PaymentService()
    payment_service_sms_notifier = PaymentService(notifier=sms_notifier)

    customer_data_with_email = CustomerData(
        name="John Doe", contact_info=ContactInfo(email="john@example.com")
    )
    customer_data_with_phone = CustomerData(
        name="John Doe", contact_info=ContactInfo(phone="1234567890")
    )

    payment_data = PaymentData(amount=100, source="tok_visa")

    payment_service_sms_notifier.process_transaction(
        customer_data_with_email, payment_data
    )
    payment_service.process_transaction(customer_data_with_phone, payment_data)

    try:
        error_payment_data = PaymentData(amount=100, source="tok_radarBlock")
        payment_service.process_transaction(
            customer_data_with_email, error_payment_data
        )
    except Exception as e:
        print(f"Payment failed and PaymentProcessor raised an exception: {e}")

Bryann Andrei Valderrama Avila

student•

¿Qué beneficios trae usar Protocolos en lugar de Clases Abstractas?

Por lo que tenía entendido los Protocolos no se heredan explícitamente ¿Por qué se hace diferente aquí?

Platzi

student•

Los protocolos permiten declarar interfaces en Python funcionando de forma similar a clases abstractas, con la diferencia de no requerir herencia explícita, lo cual otorga flexibilidad para cumplir con interfaces sin la necesidad de estructuras de herencia estrictas.

Victor Pinto

student•

Tengo la misma duda de Bryann Andrei Valderrama Avila

Incluso estuve experimentando y me permitió "romper el contrato", es decir, usar una función con variables no definidas dentro de la interface.

Mario Alexander Vargas Celis

student•

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.

Wilbertson Mojica Cifuentes

student•

En Python, las interfaces se denominan "Protocolos" porque el lenguaje utiliza esta terminología para definir un conjunto de métodos que las clases deben implementar, sin necesidad de heredar de una clase base específica. Esto se importa del módulo typing para permitir una programación más flexible y dinámica.

Los protocolos proporcionan una forma de definir interfaces de manera más informal y son una característica importante para implementar el principio de sustitución de Liskov. Esto permite que diferentes clases sean intercambiables siempre que cumplan con el mismo protocolo.

Cesar Augusto Mora Castilo

student•

Para cumplir con el principio de sustitución de Liskov la clase SMSNotifier no requiere de un parámetro adicional al que pide EMailNotifier ya que heredan de la misma clase.

La clase debe quedar:

@dataclass
class SMSNotifier(Notifier):
    sms_gateway: str

    def send_confirmation(self, customer_data: CustomerData):
        # Responsabilidad de la notificación
        phone_number = customer_data.contact_info.phone
        # sms_gateway = "the custom SMS Gateway"
        print(
            f"send the sms using {self.sms_gateway}: SMS sent to {phone_number}: \
                Thank you for your payment."
        )
```@dataclassclass SMSNotifier(Notifier):    sms\_gateway: str
&#x20;   def send\_confirmation(self, customer\_data: CustomerData):        *# Responsabilidad de la notificación*        phone\_number = customer\_data.contact\_info.phone        *# sms\_gateway = "the custom SMS Gateway"*        print(            f"send the sms using {*self*.sms\_gateway}: SMS sent to {phone\_number}: \                Thank you for your payment."        )

Cesar Augusto Mora Castilo

student•

El bug que encontré se debe a que se cambio la clase SMSNotifier, la deje así:

@dataclass
class SMSNotifier(Notifier):
    sms_gateway: str

    def send_confirmation(self, customer_data: CustomerData):
        # Responsabilidad de la notificación
        phone_number = customer_data.contact_info.phone
      
        print(
            f"send the sms using {sms_gateway}: SMS sent to {phone_number}: \
                Thank you for your payment."
        )
```Se quito la linea de código

\# sms\_gateway = "the custom SMS Gateway"

Hay que cambiar la firma de la función a:

def send\_confirmation(self, customer\_data: CustomerData, sms\_gateway):

Así que al instanciar el sms\_notifier se debe debe incluir:

sms\_notifier = SMSNotifier(sms\_gateway="the custom SMS Gateway")

Con estas modificaciones me funciono el código de nuevo.

Juan Camilo Suarez

student•

¿las interfaces son equivalentes al polimorfismo?

Principio de sustitución de Liskov en Python

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

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