Aplicación del Principio de Inversión de Dependencias en Python

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

Resumen

El principio de inversión de dependencias es clave para mejorar la arquitectura del código, y este ejemplo sobre el servicio de pagos lo ilustra perfectamente. En lugar de que la clase de alto nivel dependa de detalles de las clases de bajo nivel, se trabaja con abstracciones, lo que permite mayor flexibilidad al añadir nuevas funcionalidades.

¿Cumple el código con el principio de inversión de dependencias?

Sí, el código cumple con el principio desde el momento en que el servicio de pagos (clase de alto nivel) no depende directamente de los detalles de los procesadores de pagos, validadores o notificadores, sino de interfaces o protocolos. Esto significa que, si alguna de las implementaciones cambia, el servicio de alto nivel no requiere modificaciones, ya que interactúa únicamente con las abstracciones.

¿Qué detalles pueden mejorar para aplicar mejor el principio?

Aunque la implementación está alineada con el principio de inversión de dependencias, hay un detalle por mejorar: las clases de alto nivel aún instancian clases de bajo nivel dentro de sus atributos, como los validadores o el logger. Para eliminar esta dependencia, se recomienda remover esas “default factories” y en su lugar, inyectar todas las dependencias desde fuera del servicio. Esto garantizaría una mayor adherencia al principio.

¿Cómo se instancia el servicio de pagos aplicando el principio?

El código muestra claramente cómo se instancian las dependencias antes de crear el servicio de pagos. Se crea el procesador de pagos de Stripe, un notificador de email, los validadores de clientes y pagos, así como el logger. Luego, se pasa cada dependencia al PaymentService, asegurando que el servicio de alto nivel no conozca los detalles internos de las clases de bajo nivel.

Se instancia el procesador de Stripe y se reutiliza para recurrencias y reembolsos.
Si se requiere un servicio con otro procesador, como uno offline, el cambio es sencillo porque las clases están desacopladas.

¿Cómo permite la inyección de dependencias mejorar la flexibilidad del código?

La inyección de dependencias facilita la flexibilidad, ya que permite cambiar las implementaciones sin modificar el servicio principal. Si en lugar de Stripe se requiere otro procesador o un notificador distinto como SMS, el código solo necesita ajustar las instancias que se pasan al servicio, sin afectar el código principal.

Wilbertson Mojica Cifuentes

student•

Otro ejemplo de un codigo que aplica el DIP:

from abc import ABC, abstractmethod

class Heroe(ABC):  # Abstracción
    @abstractmethod
    def atacar(self):
        pass

class Batman(Heroe):
    def atacar(self):
        print("Batman lanza un batarang")

class Superman(Heroe):
    def atacar(self):
        print("Superman lanza su visión láser")

class SuperHeroe:
    def __init__(self, heroe: Heroe):  # Dependencia en una abstracción
        self.heroe = heroe

    def realizar_ataque(self):
        self.heroe.atacar()

# Uso
batman = Batman()
superman = Superman()

# Ahora puedes usar cualquier héroe que implemente la interfaz `Heroe`
super_heroe1 = SuperHeroe(batman)
super_heroe2 = SuperHeroe(superman)

Juan Camilo Suarez

student•

Mi solución al reto: (creo)

1 Cortar y pegar: en la clase StripePaymentProcessor están las funciones que precisamente hacen devoluciones y recurrencia, por lo que solo es cortar y pegar ese código en las respectivas clases.

2 Borrar las funciones e instanciar las clases: Luego, borras las funciones que ya no necesitan en StripePaymentProcessor, (así que ya estarías cumpliendo con el principio S), e instancias las clases así:

las interfaces PaymentProcessorProtocol, RefundPaymentProtocol, RecurringPaymentProtocol ya solo son instancias del método de la clase de StripePaymentProcessor: lo que me confunde de esto último es que, la clase en cuestión (StripePaymentProcessor) ahora sería una clase de alto nivel porque define la lógica de negocio... o no sé, agradecería si alguien puede corregirme 😅

¿Hay algo que entendí mal o que no es correcto? :<

Mario Alexander Vargas Celis

student•

El Principio de Inversión de Dependencias (DIP) establece que las clases de alto nivel no deben depender de clases de bajo nivel, sino de abstractions, como interfaces o protocolos. Los puntos básicos son:

Dependencias hacia abstracciones: Un módulo de alto nivel no debe depender de un módulo de bajo nivel. Ambos deberían depender de abstracciones.
Inversión de dependencias: Las dependencias deben ser inyectadas en lugar de ser creadas dentro de las clases, promoviendo un código más flexible y fácil de modificar.
Facilitación de pruebas: Permite que las pruebas unitarias sean más simples, ya que se pueden inyectar dependencias simuladas.

Este principio mejora la mantenibilidad y escalabilidad del código.

Minería Datos

student•

Asi lo hice, me gusraia rebir feedback:

class PaymentProcessorProtocol(Protocol):
    """
    Protocol for processing payments, refunds, and recurring payments.

    This protocol defines the interface for payment processors. Implementations
    should provide methods for processing payments, refunds, and setting up recurring payments.
    """

    def process_transaction(
        self, customer_data: CustomerData, payment_data: PaymentData
    ) -> PaymentResponse: ...


class RefundPaymentProtocol(Protocol):
    def refund_payment(self, transaction_id: str) -> PaymentResponse: ...


class RecurringPaymentProtocol(Protocol):
    def setup_recurring_payment(
        self, customer_data: CustomerData, payment_data: PaymentData
    ) -> PaymentResponse: ...


class StripePaymentProcessor(
    #PaymentProcessorProtocol, RefundPaymentProtocol, RecurringPaymentProtocol
):
    PaymentProcessorProtocol = PaymentProcessorProtocol()
    RefundPaymentProtocol = RefundPaymentProtocol()
    RecurringPaymentProtocol = RecurringPaymentProtocol()

David Agudelo

student•

La finalidad de usar from abc import ABC en Python es para definir clases abstractas. Al heredar de ABC, puedes crear métodos abstractos en la clase padre que deben ser implementados en las clases hijas. Esto garantiza que las subclases sigan un contrato específico, asegurando que ciertos métodos existan y tengan la implementación adecuada, incluso si Python permite que las clases se instancien sin estos métodos. Esto mejora la organización y la mantenibilidad del código, alineándose con los principios SOLID, especialmente la responsabilidad única y la inversión de dependencias.

Ray Trápala

student•

En esta parte, tengo entendido que la inteccion se puede hacer por medio del constructor o en el metodo no?

No sé si esto está relacionado con la composición (hablando de UML) porqué, por ejemplo, PaymentService se compone de un custom_validator que debe tener sí o sí, no? por lo tanto, podría creare una nueva instancia del mismo en el constructor, en este caso en el método post_init porque es una dataclass, es correcta mi apreciacion?

En el caso de payment_validator sería lo mismo o no?

Eduardo José Álvarez

Team Platzi•

sí, al final la inversión de dependencias está muy ligado a la composición, de hecho, es lo que permite que la composición ocurra.

Lo ideal es que la clase principal no tenga la responsabilidad de crear a las clases de las que depende, para eso se utilizar diferentes mecanismos como por ejemplo el Patrón de Diseño Builder que se ve más adelante en el curso.

Wilbertson Mojica Cifuentes

student•

Otro ejemplo sencillo de un codigo que viola el DIP:

class Batman:
    def atacar(self):
        print("Batman lanza un batarang")

class SuperHeroe:
    def __init__(self):
        self.heroe = Batman()  # Dependencia directa de una clase concreta

    def realizar_ataque(self):
        self.heroe.atacar()

# Uso
heroe = SuperHeroe()
heroe.realizar_ataque()

Cesar Augusto Mora Castilo

student•

En el código de ejemplo, las dependencias se inyectaron en la creación de la clase PaymentService. Las instancias de las dependencias como StripePaymentProcessor, EmailNotifier, CustomerValidator, PaymentValidator y Logger se pasaron como argumentos al constructor de PaymentService, garantizando que esta clase no dependa de la creación de las clases de bajo nivel.

Bryann Andrei Valderrama Avila

student•

¿Cómo se podría obtener el STRIPE_PRICE_ID?