Implementación del Principio Abierto-Cerrado en Procesadores de Pago y Notificadores

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

Resumen

El principio de abierto-cerrado promueve la creación de código que permita extender funcionalidades sin modificar el comportamiento original. A continuación, veremos cómo se puede aplicar este principio en el contexto de un procesador de pagos que debe añadir nuevas pasarelas sin cambiar el código existente.

¿Cómo se aplica el principio abierto-cerrado en un procesador de pagos?

La clave para implementar el principio abierto-cerrado en un sistema de pagos es diseñar el código de manera que pueda admitir nuevas pasarelas sin modificar la estructura existente. Esto se logra utilizando clases abstractas o interfaces que actúan como intermediarios. Así, los procesadores de pagos específicos, como Stripe, pueden heredar de estas clases abstractas y añadir su propia lógica sin afectar el código original.

¿Qué cambios se hicieron para implementar una nueva pasarela?

Para incorporar una nueva pasarela de pagos en este caso:

Se creó una nueva carpeta con ejemplos de antes y después de aplicar el principio abierto-cerrado.
Los datos del cliente y el pago se refactorizaron utilizando Pydantic, que es la librería más popular en Python para validaciones de datos.
Se introdujeron modelos de datos tipados para CustomerData y PaymentData, con campos claros como montos (enteros) y fuentes de pago (cadenas de texto).

¿Cómo se manejan los datos con Pydantic?

Pydantic permite definir modelos de datos que facilitan la validación y tipado. Por ejemplo, el modelo CustomerData contiene atributos como name (nombre del cliente) y contact_info (información de contacto), que incluye campos opcionales como teléfono o correo electrónico. Esto hace que la manipulación de datos sea más clara y segura.

¿Cómo se crean nuevas pasarelas de pagos usando clases abstractas?

Primero, se define una clase abstracta que representará un procesador de pagos. Esta clase no contiene lógica interna, sino que se utiliza para definir la firma del método principal, processTransaction. Los procesadores de pagos como Stripe implementan esta clase abstracta, heredando su forma y añadiendo la lógica específica para procesar las transacciones.

Se define una clase abstracta PaymentProcessor que incluye el método processTransaction.
Stripe, por ejemplo, hereda de esta clase abstracta para implementar su propia lógica de procesamiento.
El servicio de pagos ya no depende de la implementación concreta de Stripe, sino que interactúa con la clase abstracta, lo que facilita añadir nuevas pasarelas sin tocar el código base.

¿Cómo se manejan las notificaciones de confirmación?

Se siguió una estrategia similar para las notificaciones. Al igual que con los procesadores de pagos, se creó una clase abstracta Notifier que define la firma del método SendConfirmation. Esto permite crear diferentes implementaciones, como un notificador por correo electrónico o un notificador por SMS, sin afectar la estructura del código original.

Se introdujo un EmailNotifier y un SMSNotifier, ambos heredando de la clase abstracta Notifier.
El código decide dinámicamente qué tipo de notificación enviar según los datos del cliente, ya sea por correo o por SMS.

¿Cómo se extendió el código sin modificar su estructura original?

Al final, el servicio de pagos se extendió para que permitiera enviar notificaciones vía SMS sin cambiar su base de código. Esto se logró creando una nueva clase SMSNotifier que también hereda de Notifier. El código puede cambiar entre el envío de correos o mensajes de texto con solo ajustar la implementación del servicio, cumpliendo así con el principio abierto-cerrado.

Ray Trápala

student•

Porque no hacen esos cambios antes de terminar el video, al menos, a mi me confunde eso cuando debieron hacerlo de antes por eso el archivo es before

Oscar Barajas Tavares

Team Platzi•

Cuéntame Ray, como te ayudo a continuar tu aprendizaje.

Ray Trápala

student•

pues solo me retrasa un poco porque de venir con una estructura me tengo q detener de más. Creo se debe explicar esos detalles más a fondo porque me tocó investigar un poco más porque no estoy acostumbrado con pydantic.

Juan Alarcon

student•

el video esta mal editado, repite en el min 5:13 una idea ya expuesta

JHONATAN DAVID RESTREPO HENAO

student•

🧠 Preguntas clave para saber si necesitas OCP

¿Necesito modificar una clase o función cada vez que agrego una nueva funcionalidad? (Si es así, aplica OCP).
¿Puedo extender la funcionalidad agregando una nueva clase en lugar de modificar una existente?
¿Hay muchos if/else o switch/case que podrían convertirse en clases separadas?
¿Cada vez que hay un cambio en las reglas de negocio, tengo que modificar el código existente?

Carlos Rodriguez

student•

Asignar una clase por defecto directamente puede causar problemas porque si la clase contiene atributos mutables, todas las instancias compartirán la misma referencia a esos atributos. Esto significa que un cambio en una instancia afectará a todas las demás, rompiendo la integridad de los datos. Es fundamental en aplicaciones donde múltiples instancias coexisten, ya que cada objeto debería tener su propio estado independiente. Para evitar esto, se recomienda usar un default_factory que cree nuevas instancias en lugar de compartir la misma.

Mario Alexander Vargas Celis

student•

Para aplicar el **Principio Abierto/Cerrado** (Open/Closed Principle, OCP), necesitamos estructurar el código de manera que se pueda **extender sin modificar** el código existente. Esto se puede hacer mediante la creación de clases abstractas o interfaces que se implementan o heredan en clases específicas, permitiendo la adición de nuevas funcionalidades sin cambiar la clase base.

A continuación, te muestro un ejemplo y cómo aplicarle el OCP.

### Ejemplo de Código que Viola el OCP

Supongamos que estamos desarrollando un sistema para calcular el costo de envío de un pedido. Inicialmente, solo tenemos el cálculo de envío estándar, pero más adelante necesitamos agregar otros tipos de envío, como envío exprés y envío internacional. Una implementación que viola el OCP podría verse así:


class ShippingCalculator:

&#x20;   def calculate\_shipping(self, order, shipping\_type):

&#x20;       if shipping\_type == "standard":

&#x20;           return order.weight \* 5  # Envío estándar: $5 por kg

&#x20;       elif shipping\_type == "express":

&#x20;           return order.weight \* 10  # Envío exprés: $10 por kg

&#x20;       elif shipping\_type == "international":

&#x20;           return order.weight \* 20  # Envío internacional: $20 por kg

&#x20;       else:

&#x20;           raise ValueError("Invalid shipping type")

Cada vez que se agrega un nuevo tipo de envío, hay que modificar la clase ShippingCalculator, lo cual viola el principio OCP, ya que no está **cerrada a modificaciones**.

### Solución: Aplicando el OCP

Para cumplir con el principio OCP, podemos crear una clase base o interfaz llamada ShippingStrategy y luego extenderla para cada tipo de envío, manteniendo el código de ShippingCalculator **cerrado a modificaciones** pero **abierto a la extensión**.


from abc import ABC, abstractmethod



\# Interfaz o clase abstracta para la estrategia de envío

class ShippingStrategy(ABC):

&#x20;   @abstractmethod

&#x20;   def calculate(self, order):

&#x20;       pass



\# Estrategia de envío estándar

class StandardShipping(ShippingStrategy):

&#x20;   def calculate(self, order):

&#x20;       return order.weight \* 5



\# Estrategia de envío exprés

class ExpressShipping(ShippingStrategy):

&#x20;   def calculate(self, order):

&#x20;       return order.weight \* 10



\# Estrategia de envío internacional

class InternationalShipping(ShippingStrategy):

&#x20;   def calculate(self, order):

&#x20;       return order.weight \* 20



\# Clase principal que utiliza la estrategia de envío

class ShippingCalculator:

&#x20;   def \_\_init\_\_(self, strategy: ShippingStrategy):

&#x20;       self.strategy = strategy



&#x20;   def calculate\_shipping(self, order):

&#x20;       return self.strategy.calculate(order)

### Explicación

- **Clase ShippingStrategy**: Es una clase abstracta que define el método calculate. Esta clase sirve como interfaz para las estrategias de envío.

- **Clases StandardShipping, ExpressShipping, InternationalShipping**: Implementan ShippingStrategy y proporcionan el cálculo específico de cada tipo de envío.

- **Clase ShippingCalculator**: Utiliza una instancia de ShippingStrategy para calcular el costo de envío sin importar el tipo. De esta manera, se puede extender ShippingCalculator con nuevos tipos de envío sin modificar su código.

### Uso del Código

Supongamos que tenemos un objeto order con un atributo weight. Así es como podríamos calcular el costo de envío usando diferentes estrategias:


class Order:

&#x20;   def \_\_init\_\_(self, weight):

&#x20;       self.weight = weight



\# Crear un pedido

order = Order(weight=10)  # Ejemplo de pedido de 10 kg



\# Calcular el costo de envío estándar

calculator = ShippingCalculator(StandardShipping())

print(f"Envío estándar: ${calculator.calculate\_shipping(order)}")



\# Calcular el costo de envío exprés

calculator.strategy = ExpressShipping()

print(f"Envío exprés: ${calculator.calculate\_shipping(order)}")



\# Calcular el costo de envío internacional

calculator.strategy = InternationalShipping()

print(f"Envío internacional: ${calculator.calculate\_shipping(order)}")

### Ventajas de Aplicar el OCP

1. **Extensibilidad**: Podemos añadir nuevos tipos de envío (por ejemplo, "Envío nocturno") simplemente creando una nueva clase que herede de ShippingStrategy, sin necesidad de modificar ShippingCalculator.

2. **Mantenibilidad**: Al no tener que modificar ShippingCalculator, se reduce el riesgo de introducir errores en la lógica existente.

3. **Reusabilidad**: Cada estrategia de envío es una clase independiente, por lo que puede reutilizarse y probarse de forma aislada.

### Conclusión

Al aplicar el **Principio Abierto/Cerrado** hemos hecho que el código sea más **modular** y fácil de **extender**. Esto nos permite agregar funcionalidades nuevas sin necesidad de modificar el código existente, lo cual es esencial para mantener un sistema robusto y escalable.

Sergio Cassia

student•

Excelente ejemplo. Muchas gracias por el esfuerzo.

Edgar Hernandez

student•

En el principio abierto cerrado que pasaria si al implementar otro paymentProcessor este requiere de otros atributos? Se usaria kwargs??

Ray Trápala

student•

En sí, pydantic para qué es? para hacer clases o solo para representar estructuras de diccionarios de una mejor manera?

Oscar Barajas Tavares

Team Platzi•

Pydantic es una biblioteca de Python para la validación de datos y la gestión de configuraciones mediante el uso de modelos de datos basados en anotaciones de tipo.

Ronaldo Jiménez

student•

FastAPI utiliza Pydantic, ya que este proporciona una forma sencilla y eficiente de definir y validar datos, así aprovecha dichas capacidades para crear APIs rápidas, seguras y bien documentadas.

Leonel Marinaro

student•

Estaria bueno que compartan un archivo donde compartan las configuraciones de vscode de cada curso, por ejemplo, de este curso me gusta el theme pero debo buscar manualmente cuál es.

Angel Eduardo Arizpe Carrillo

student•

Son varios los cambios que hizo al código utilizando Pydantic previos a empezar la clase, me gustaría que no hicieran eso antes para evitar confusiones, tuve que ubicar varios de esos cambios para hacerlos porque no los tenía, especialmente en las firmas de los métodos. No lo digo como algo demasiado malo, solo como un detalle que hace que pauses el video muchas veces y pierdas el foco de lo que estás haciendo

Jimmy Valladares

student•

concuerdo contigo

Emilio Sala

student•

No le veo sentido hacer una clase dataclass si no tiene atributos. Respecto a las interfaces también se puede usar Protocol, un poco más flexible y nos evita la herencia.

Wilbertson Mojica Cifuentes

student•

Otro ejemplo de uso de OCP

Sin OCP: Aqui se viola el principio porque para agregar un nuevo tipo de descuento se tendria que modificar la clase DiscountCalculator

class DiscountCalculator:
    def __init__(self, discount_type, amount):
        self.discount_type = discount_type
        self.amount = amount

    def calculate_discount(self):
        if self.discount_type == "percentage":
            return self.amount * 0.10
        elif self.discount_type == "fixed":
            return 20
        elif self.discount_type == "seasonal":
            return self.amount * 0.15
        else:
            return 0

# Uso del calculador de descuentos
calculator = DiscountCalculator("seasonal", 100)
```Con OCP:

```python
from abc import ABC, abstractmethod

class DiscountStrategy(ABC):
    @abstractmethod
    def calculate_discount(self, amount):
        pass

class PercentageDiscount(DiscountStrategy):
    def calculate_discount(self, amount):
        return amount * 0.10

class FixedDiscount(DiscountStrategy):
    def calculate_discount(self, amount):
        return 20


class DiscountCalculator:
    def __init__(self, strategy: DiscountStrategy, amount):
        self.strategy = strategy
        self.amount = amount

    def calculate_discount(self):
        return self.strategy.calculate_discount(self.amount)

# Uso del calculador de descuentos
calculator = DiscountCalculator(SeasonalDiscount(), 100)

Wilbertson Mojica Cifuentes

student•

Bueno estas clases si me tomo mas comprenderlas, aqui mis conclusiones:

El OCP se viola cuando tenemos una clase en al cual tenemos una logica que tenga que modificarse cuando queremos agregar una nueva funcionalidad. El ejemplo de la clase no queda claro como se viola el principio porque la clase se llama StripePaymentProcessor, quizas debio llamarse solo PaymentProcesor ya que si queremos implementar otra pasarela tendriamos que modificar esa clase lo cual violaria el principio. Pero aqui podriamos crear otra clase como PayPalPaymentProcessor sin modificar la de StripePaymentProcessor y no estariamos violando el principio.

David Agudelo

student•

Este curso va a una velocidad de vértigo. (Y ME ENCANTA!!).

Tuve que pausar el curso para entender primero los siguientes conceptos y librerías:

API (public - Secret keys)
Dotenv - load_dovenv() - .env
ABS (Clases abstractas)
@Dataclass
Pydantic

Alan Miguel Perez Osorio

student•

Una clase abstracta es una clase que no puede ser instanciada directamente y sirve como base para otras clases. Es utilizada para definir una interfaz común y establecer métodos que deben ser implementados por las clases derivadas. En el contexto de Python, se crea utilizando el módulo abc y su propósito es garantizar que las subclases sigan un contrato específico. Esto es fundamental para aplicar principios como el Abierto-Cerrado, permitiendo extender funcionalidad sin modificar el código existente.

Ederson Felipe Lopez Bolivar

student•

Para que sirve el la funcion field al momento de instanciar un objeto?

Franco Coloccini

student•

Puede considerarse esta implementación de Notifier como una forma del patrón Strategy? De no ser así, cuál sería la diferencia?

Platzi

student•

Sí, se considera una implementación del patrón Strategy. El atributo notificador del Service se utiliza como una interfaz para múltiples estrategias de notificación y el método setNotifier permite cambiar la estrategia en tiempo de ejecución según el contexto.

Martin Ruggeri

student•

Esta bueno pero... por que no hacer lo del field para todos ??? ''' @dataclass

class PaymentService:

customer_validator: CustomerValidator = field(default_factory=CustomerValidator)

payment_validator: PaymentDataValidator = field(default_factory=PaymentDataValidator)

payment_processor: PaymentProcessor = field(default_factory=StripePaymentProcessor)

notifier: Notifier = field(default_factory=EmailNotifier)

logger: TransactionLogger = field(default_factory=TransactionLogger) '''

edgardo ponce

student•

Muy bien! estoy aprendiendo cosas nuevas. Gracias gracias.

Leonel Marinaro

student•

Este curso es realmente increible!! Por favor hagan más cursos de este nivel de conocimientos. Felicitaciones!!

Leonardo daniel Gutierrez Medellin

student•

Pydantic es una biblioteca de Python que permite la validación de datos y la creación de modelos de datos utilizando la programación orientada a objetos. Facilita la definición de estructuras de datos y asegura que los datos cumplen con un esquema específico.

Ejemplo básico:

from pydantic import BaseModel

class CustomerData(BaseModel):
    name: str
    email: str
    phone: str = None  # opcional

customer = CustomerData(name="Juan", email="juan@example.com")
print(customer)

Este código crea un modelo CustomerData que valida que name y email sean cadenas. Al crear una instancia, Pydantic verifica automáticamente que los datos proporcionados sean correctos.