Aplicación del Principio Abierto Cerrado en Python con Pydantic

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

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

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í: ```python class ShippingCalculator: def calculate\_shipping(self, order, shipping\_type): if shipping\_type == "standard": return order.weight \* 5 # Envío estándar: $5 por kg elif shipping\_type == "express": return order.weight \* 10 # Envío exprés: $10 por kg elif shipping\_type == "international": return order.weight \* 20 # Envío internacional: $20 por kg else: 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\*\*. ```python from abc import ABC, abstractmethod \# Interfaz o clase abstracta para la estrategia de envío class ShippingStrategy(ABC): @abstractmethod def calculate(self, order): pass \# Estrategia de envío estándar class StandardShipping(ShippingStrategy): def calculate(self, order): return order.weight \* 5 \# Estrategia de envío exprés class ExpressShipping(ShippingStrategy): def calculate(self, order): return order.weight \* 10 \# Estrategia de envío internacional class InternationalShipping(ShippingStrategy): def calculate(self, order): return order.weight \* 20 \# Clase principal que utiliza la estrategia de envío class ShippingCalculator: def \_\_init\_\_(self, strategy: ShippingStrategy): self.strategy = strategy def calculate\_shipping(self, order): 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: ```python class Order: def \_\_init\_\_(self, weight): 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.

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.

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

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 ```python 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) ```

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.

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

Muy bien! estoy aprendiendo cosas nuevas. Gracias gracias.

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.

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

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: ```python from pydantic import BaseModel class CustomerData(BaseModel): name: str email: str phone: str = None # opcional customer = CustomerData(name="Juan", email="[email protected]") 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.

Las interfaces (o en Python, clases abstractas) son fundamentales en este caso porque definen una "regla" o "contrato" que todas las implementaciones deben seguir. En este caso la clase PaymentProcessor establece que cualquier nueva pasarela que se quiera implementar su clase debera tener un metodo process\_transaction