Principio de inversión de dependencias: servicio de pagos flexible

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:005:56

Principio de inversión de dependencias: servicio de pagos flexible

Curso de Patrones de Diseño y SOLID en Python

Clase 12 de 27

Clase 12 / 27

Recursos

Aplicar el principio de inversión de dependencias en un servicio de pagos permite cambiar procesadores como Stripe u opciones offline sin tocar la lógica de alto nivel. Aquí verás cómo componer el Payment Service con protocolos, eliminar default factories e introducir inyección de dependencias para manejar cobros, recurrencias y reembolsos de forma limpia.

¿Qué asegura el principio de inversión de dependencias en el servicio de pagos?

El servicio (clase de alto nivel) no depende de detalles de clases de bajo nivel, sino de interfaces; en Python, de protocolos. Los detalles viven en los procesadores de pago que hablan con distintas pasarelas. Si se cambia el protocolo, se ajustan las implementaciones, pero el servicio se mantiene estable.

Clase de alto nivel: Payment Service. Depende de protocolos, no de implementaciones concretas.
Clases de bajo nivel: procesadores de pago, notificador, validadores, logger.
Protocolos en Python: definen el contrato. La implementación puede variar sin afectar al servicio.
Recurrencia y reembolsos: pueden usar la misma instancia del procesador (por ejemplo, Stripe) si cumple los protocolos.
Beneficio clave: menor acoplamiento y mayor facilidad de reemplazo.

¿Cómo instanciar dependencias sin default factories?

Para cumplir a fondo el principio, se eliminan los default factories del servicio: la clase de alto nivel no debe saber cómo instanciar clases de bajo nivel. En su lugar, se reciben como dependencias ya construidas.

# Dependencias de bajo nivel
stripe_processor = StripePaymentProcessor()
email_notifier = EmailNotifier()
customer_validator = CustomerValidator()
payment_validator = PaymentValidator()
logger = TransactionLogger()

# Clase de alto nivel: composición explícita
payment_service = PaymentService(
    payment_processor=stripe_processor,
    notifier=email_notifier,
    customer_validator=customer_validator,
    payment_validator=payment_validator,
    logger=logger,
    recurrence_processor=stripe_processor,   # reutiliza Stripe para recurrencia
    refund_processor=stripe_processor        # reutiliza Stripe para reembolsos
)

default factories: se remueven del servicio para evitar acoplar construcción con lógica.
Instanciación limpia: cada dependencia se crea fuera y se inyecta.
Reutilización: Stripe cumple protocolos de recurrencia y reembolso, por eso se usa la misma instancia.

¿Cómo cambiar implementaciones con inyección de dependencias?

La inyección de dependencias permite intercambiar implementaciones sin modificar el servicio. Esto abre la puerta a usar un contenedor de inyección de dependencias en escenarios reales, aunque aquí se simula con composición manual.

# Nuevas implementaciones de bajo nivel
offline_processor = OfflineProcessor()
sms_notifier = SMSNotifier(gateway="custom_gateway")

# Segundo servicio con otras dependencias y sin recurrencia/reembolsos
second_service = PaymentService(
    payment_processor=offline_processor,
    notifier=sms_notifier,
    customer_validator=customer_validator,
    payment_validator=payment_validator,
    logger=logger
)

Intercambiabilidad: cambia Stripe por offline processor sin tocar la lógica de alto nivel.
Notificadores: alterna entre Email Notifier y SMS notifier según necesidad.
Configuración: elimina recurrencia y reembolsos cuando no aplican.

¿Qué habilidades y conceptos practicas?

Diferenciar clase de alto nivel vs clases de bajo nivel.
Programar contra interfaces/protocolos para reducir acoplamiento.
Eliminar default factories en el servicio para respetar el principio.
Aplicar inyección de dependencias para componer servicios flexibles.
Reutilizar instancias cuando cumplen múltiples protocolos: menos complejidad.
Preparar el terreno para un contenedor de inyección de dependencias más adelante.

¿De qué forma aplicarías el principio de inversión de dependencias en tu propio flujo de pagos o notificaciones? Comparte tu enfoque y, si te animas, integra los casos de cobro, recurrencia y reembolso practicando esta misma composición de dependencias.

Josué Herrera

Hace 10 meses

En resumen, de esta manera se aplica el dependency_inversion en las piezas de codigo que son mostradas en clase:

from abc import ABC, abstractmethod
from dataclasses import dataclass
from pydantic import BaseModel
import stripe 
from stripe import StripeError 
import uuid  

# Type hinting for the payment response
class PaymentResponse(BaseModel):
    status: str
    amount: float
    transaction_id: str
    message: str
# Abstraction
class PaymentProcessor(ABC):  
    @abstractmethod
    def process_transaction(self, customer_data, payment_data) -> PaymentResponse:
        ...
# Payment Type 1
@dataclass
class StripePaymentProcessor(PaymentProcessor):
    def process_transaction(self, customer_data, payment_data) -> PaymentResponse:  
        stripe.api_key = os.getenv("STRIPE_API_KEY") 
        # Payment processing responsibility
        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 PaymentResponse(
                status=charge["status"],
                amount=charge["amount"],
                transaction_id=charge["id"],
                message="Payment successful",
            )
        except StripeError as e:
            print("Payment failed:", e)
            return PaymentResponse(
                status="failed",
                amount=payment_data["amount"],
                transaction_id=None,
                message=str(e),
            )
# Payment Type 2
@dataclass
class OfflinePaymentProcessor(PaymentProcessor):
    def process_transaction(self, customer_data, payment_data) -> PaymentResponse:
        print("Processing offline payment for", customer_data["name"])
        return PaymentResponse(
            status="success",
            amount=payment_data["amount"],
            transaction_id=str(uuid.uuid4()),
            message="Offline payment successful"
        )
# Here is where the magic happens:
# In the below class 'PaymentService', the Dependency 'payment_processor' is an Abstraction of PaymentProcessor, which means once PaymentService is instantiated it can have as any Payment Type as argument, but, it follows PaymentProcessor contract.
@dataclass
class PaymentService:
    # The high-level class depends on the PaymentProcessor abstraction instead of concrete implementations.
    # This allows swapping StripePaymentProcessor, OfflinePaymentProcessor, etc. without modifying PaymentService,
    # preserving OCP and avoiding tight coupling — otherwise changing payment logic would force modifying this class,
    # breaking both OCP and DIP.
    payment_processor: PaymentProcessor  
    def process_transaction(self, customer_data, payment_data) -> PaymentResponse:
        try:
            self.customer_validator.validate(customer_data)
        except ValueError as e:
            raise e 
        try:
            self.payment_validator.validate(payment_data)
        except ValueError as e:
            raise e  
        try:
            charge = self.payment_processor.process_transaction(customer_data, payment_data)
            self.notifier.send_confirmation(customer_data)
            self.logger.log(customer_data, payment_data, charge)
            return charge
        except StripeError as e:
            raise e

# Usage, first we instantiate the Payment Type 1 and 2
stripe_payment_processor = StripePaymentProcessor()
offline_payment_processor = OfflinePaymentProcessor()
 
# Any implementation of PaymentProcessor can be swapped here without modifying PaymentService.
stripe = PaymentService(payment_processor=stripe_payment_processor)
offline = PaymentService(payment_processor=offline_payment_processor)

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 inversión de dependencias: servicio de pagos flexible

Progreso del curso

Patrones de Diseño y Principios SOLID

Principios SOLID

Reestructuración del proyecto

Patrones de Diseño

Recursos

Recursos