Aplicación del Principio de Sustitución de Liskov en Python

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

Resumen

El principio de sustitución de Liskov nos permite escribir código flexible y reutilizable, pero también requiere que todas las clases o protocolos cumplan con una firma coherente. En esta clase, hemos aplicado este principio en Python reemplazando las clases abstractas con protocolos y detectando un bug deliberado que rompe este principio. Vamos a analizar cómo lo resolvimos y cómo aseguramos que las clases de notificación sean intercambiables sin modificar el código base.

¿Cómo reemplazamos las clases abstractas por protocolos?

Se sustituyeron las clases abstractas por protocolos en Python.
Los protocolos actúan de manera similar a las interfaces en otros lenguajes de programación.
En este caso, el Notifier y el PaymentProcessor fueron convertidos en protocolos.
Los métodos dentro de los protocolos fueron documentados usando docstrings en formato NumPy para mejorar la claridad.

¿Cómo se introdujo y detectó el bug?

Se introdujo un bug a propósito al cambiar la clase SMSNotifier.
El bug hizo que el método SendConfirmation no cumpliera con la firma requerida, ya que estaba aceptando un parámetro adicional: SMSGateway.
Esto provocaba que no fuera intercambiable con la clase EmailNotifier, lo que viola el principio de sustitución de Liskov.
Para detectarlo, se utilizó el debugger y un análisis de la firma del método.

¿Qué desafíos presenta el principio de sustitución de Liskov?

Mantener la consistencia en las firmas de los métodos entre clases hijas y protocolos es crucial.
Es fundamental evitar introducir parámetros adicionales o cambiar las firmas de los métodos, ya que esto rompe la intercambiabilidad de las clases.

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?