Aplicar el Principio de Responsabilidad Única (SRP)

todos habeis olido el codeSmell del minuto 19:00? exacto, está repitiendo exept ValueError as e los try/except a efectos de computo son más costosos que los if, lo ideal en este caso es tener todos los validadores dentro del try y retornar un solo except con el ValueError, porque nos da igual que ValueError sea, el except los captará y retornará independientemente del que sea. no sé si lo corregirá en videos futuros pero, seguro que más de uno se dió cuenta! ese principio no es de solid, pero se llama DRY (dont repeat yourself). excelente video profesor, no hate, nadie es perfecto, solo un pequeño apunte para ayudar a la comunidad :)

Excelente material! Apenas 4 clases y ya se nota la calidad del curso. En lo personal no me agradan los cursos con clases de más de 10 minutos, pero este fue la excepción. Tan bueno es el material que te engancha, ni si quiera me había dado cuenta de los más de 20 minutos que contiene esta clase. Bien por Platzi, bien por el profe.

No sé que tan de acuerdo estén con esto. Al menos esta clase me deja esto: \- Importante diferenciar las responsabilidades ya que en base a esto podemos identificar las clases necesarias. A mi parecer, esto es experiencia y/o mucha práctica.- Cuando tenemos un código que tiene una interacción con alguna otra librería y/o aplicación, debemos seperar este código a una clase que nos sirva como "puente" de comunicación con la lógica y la librería. Esto con la finalidad de que, si la librería cambia solo debamos modificar en un lugar. A estas clases, generalmente, las nombramos como \_services\_.- Una dataclass permite usar POO de una manera más sencilla y así poder trabajar mejor así como diferenciar responsabilidades y poder aplicar SOLID

Un `dataclass` en Python es una clase que se utiliza principalmente para almacenar datos. Te permite definir clases de manera más sencilla y con menos código mediante la automatización de la creación de métodos como `__init__`, `__repr__`, y `__eq__`. Ejemplo de uso de un `dataclass`: ```python from dataclasses import dataclass @dataclass class Product: name: str price: float quantity: int product = Product(name="Laptop", price=999.99, quantity=10) print(product) # Output: Product(name='Laptop', price=999.99, quantity=10) ``` Este ejemplo muestra cómo se define un `dataclass` llamado `Product`, que automáticamente maneja la inicialización y representación de la instancia.

Crear clases separadas para validar los datos del cliente y del pago refuerza el principio de responsabilidad única (SRP) al encapsular la lógica específica de cada responsabilidad en su propia clase. Aunque métodos independientes podrían parecer suficientes, agrupar funciones relacionadas en clases mejora la cohesión y la mantenibilidad del código. Esto permite una mejor gestión de los cambios, ya que cada clase se ocupa de su propia lógica, facilitando pruebas unitarias y futuras extensiones del sistema sin afectar otras partes del código.

La clase `CustomerValidator` debe ser utilizada en lugar de una función para encapsular la lógica de validación y mantener el estado si es necesario. Esto permite aplicar principios de programación orientada a objetos, como la reutilización y la separación de responsabilidades, lo que es clave en el desarrollo de software escalable y mantenible. Al crear una clase, puedes instanciarla y extender su funcionalidad fácilmente, además de mejorar la organización del código. Esto se alinea con el Principio de Responsabilidad Única, separando la lógica de validación del resto del proceso de pago.

La elección entre Pydantic y dataclasses depende del contexto de uso. - **Pydantic** es excelente para la validación de datos y la manipulación de configuraciones, ya que proporciona características como la validación automática y el soporte para tipos complejos. Es ideal para aplicaciones donde la validación de datos es crítica, como en APIs. - **Dataclasses** son más simples y livianas, perfectas para estructuras de datos sin validación adicional. Se utilizan cuando no se necesita la funcionalidad extra de validación y sólo se requiere una representación eficiente de los datos. Si la validación es una prioridad, Pydantic es la mejor opción.

No me hace sentido poner esto o sus equivalentes: ```python def process_transaction(self, customer_data, payment_data) -> Charge: try: self.customer_validator.validate(customer_data) self.payment_validator.validate(payment_data) except ValueError as e: raise ValueError("Invalid data:", e) ``` considero que un `try except` se deberia de utilizar cuando uno no tiene el control de las cosas y quiere ponerle control y queres ejecutar algo en funcion del error, en este caso, solo es una validación y es raro hacer un `raise` del mismo error que ya viene del Validator, un ejemplo mas funcional es como cuando usas un paquete externo (en este caso stripe) y queres regresar un custom error, quitando lo que el propio paquete ya retorna (evitando exponer datos) o en transacciones de DB para hcer un rollback de varias inserciones en varias tables si alguna da error

al inicio del curso cuando el profe dijo que ibamos a crear una pasarela de pagos , me emocioné bastante , pero cuando ví que ya literalmente todo esta creado y que solo es copiar y pegar , se me quitaron las ganas de seguir viendo este curso

Como recomendación eviten utilizar variables con nombre como a,e,i,o,u ya que realmente el nombre no representa el valor que almacena correctamente.

Como nota general, no deberiamos tener tantas instrucciones dentro de un try/except, esto permite que si falla una operación se puede identificar de manera rapida.

Para darle el nombre correcto a las validaciones que devuelven una excepcion y que cortan el flujo eso se llama: Early return. Esto permite mantener el código limpio y sin tanta indentación

El método `customer_data.get("name")` se utiliza para acceder de manera segura al valor del campo "name" dentro del diccionario `customer_data`. Si "name" no existe, `get` devuelve `None` en lugar de generar un error, lo que permite manejar la ausencia de datos sin interrumpir la ejecución del programa. Esto es especialmente útil en validaciones, ya que se puede verificar si el nombre está presente antes de proceder con la lógica de procesamiento del pago. Este enfoque concuerda con el principio de responsabilidad única, al mantener la validación de datos separada del resto de la lógica.

| **Cosa por hacer** | **Descripción** | **Pasos** | |------------------------------|---------------------------------------------------------------|------------------------------------------------------------------------------------------------------------| | **1. Identificar responsabilidades** | Analizar el código y encontrar responsabilidades de cada clase. | - Revisa el código existente.
- Enumera las responsabilidades. | | **2. Aplicar SRP** | Asegurarte que cada clase tenga una única responsabilidad. | - Divide las funcionalidades en clases individuales.
- Asegúrate de que cada clase actúe de manera independiente. | | **3. Simplificar la lógica** | Hacer que el código sea más claro y fácil de entender. | - Elimina duplicaciones.
- Utiliza nombres descriptivos para métodos y variables. | | **4. Usar patrones de diseño**| Implementar patrones que faciliten la escalabilidad. | - Identifica patrones aplicables (ej. Singleton, Factory).
- Implementa el patrón en el contexto adecuado. | | **5. Escribir pruebas unitarias** | Asegurarte que el código funcione como se espera. | - Crea pruebas para cada clase nueva.
- Ejecuta las pruebas y valida que todas pasen. | | **6. Documentar cambios** | Mantener un registro de las modificaciones realizadas. | - Actualiza la documentación y comentarios.
- Asegúrate de que sea comprensible para otros desarrolladores. | | **7. Revisar rendimiento** | Comprobar que no haya degradación en el rendimiento. | - Realiza pruebas de rendimiento.
- Optimiza donde sea necesario. |

Para aplicar el \*\*Principio de Responsabilidad Única\*\* (SRP), dividimos las funcionalidades de una clase o módulo en diferentes partes, de modo que cada parte tenga \*\*una única responsabilidad\*\*. Esto permite que cada clase o función tenga un propósito específico, lo que facilita la lectura, el mantenimiento y la extensión del código. \### Ejemplo de Aplicación de SRP Supongamos que estamos desarrollando una aplicación para gestionar los pedidos en una tienda en línea. A continuación, tenemos una clase `Order` que viola el principio SRP. ```python class Order: def \_\_init\_\_(self, order\_id, items): self.order\_id = order\_id self.items = items def calculate\_total(self): total = sum(item\['price'] \* item\['quantity'] for item in self.items) return total def save\_to\_database(self): print(f"Saving order {self.order\_id} to database") def send\_confirmation\_email(self): print(f"Sending confirmation email for order {self.order\_id}") ``` Aquí, la clase `Order` tiene \*\*tres responsabilidades\*\*: 1\. \*\*Calcular el total del pedido.\*\* 2\. \*\*Guardar el pedido en la base de datos.\*\* 3\. \*\*Enviar un correo de confirmación.\*\* Esta clase viola SRP porque mezcla varias funcionalidades, lo cual complica el mantenimiento. Para aplicar SRP, debemos dividir estas responsabilidades en clases o módulos separados. \### Solución: Aplicando SRP Dividimos las responsabilidades en diferentes clases, de modo que cada clase tenga una sola responsabilidad. ```python class Order: def \_\_init\_\_(self, order\_id, items): self.order\_id = order\_id self.items = items class OrderCalculator: @staticmethod def calculate\_total(order: Order): total = sum(item\['price'] \* item\['quantity'] for item in order.items) return total class OrderRepository: @staticmethod def save(order: Order): print(f"Saving order {order.order\_id} to database") class EmailService: @staticmethod def send\_confirmation\_email(order: Order): print(f"Sending confirmation email for order {order.order\_id}") ``` \### Explicación \- \*\*Clase `Order`\*\*: Contiene solo los datos del pedido, como el identificador y los artículos. \- \*\*Clase `OrderCalculator`\*\*: Su única responsabilidad es calcular el total del pedido. \- \*\*Clase `OrderRepository`\*\*: Solo se encarga de guardar el pedido en la base de datos. \- \*\*Clase `EmailService`\*\*: Su única responsabilidad es enviar el correo electrónico de confirmación. \### Uso del Código Ahora, podemos utilizar estas clases de forma modular. Cada clase cumple con una responsabilidad específica. ```python \# Crear el pedido order = Order(order\_id=123, items=\[ {"name": "Product A", "price": 10, "quantity": 2}, {"name": "Product B", "price": 20, "quantity": 1}, ]) \# Calcular total total = OrderCalculator.calculate\_total(order) print(f"Total: ${total}") \# Guardar pedido en la base de datos OrderRepository.save(order) \# Enviar confirmación de correo EmailService.send\_confirmation\_email(order) ``` \### Ventajas de Aplicar SRP 1\. \*\*Modularidad\*\*: Al dividir las responsabilidades en varias clases, el código es más modular y fácil de entender. 2\. \*\*Facilidad de Mantenimiento\*\*: Si necesitas cambiar la lógica de cálculo, guardado o envío de correos, puedes hacerlo en la clase correspondiente sin afectar el resto del código. 3\. \*\*Posibilidad de Reutilización\*\*: Las clases `OrderCalculator`, `OrderRepository` y `EmailService` pueden reutilizarse en otros contextos sin necesidad de modificarlas. \### Conclusión Aplicar SRP mejora la organización y estructura del código, reduciendo el acoplamiento y aumentando la cohesión. Esto permite un desarrollo más robusto y adaptable a futuros cambios.