Aplicación del Principio de Responsabilidad Única en Procesador de Pagos

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

Resumen

Para aplicar el principio de responsabilidad única (SRP) sobre un procesador de pagos en Python, se debe organizar el código para que cada clase o método tenga una única responsabilidad. A continuación, te explicaré cómo refactorizar el código original, identificando responsabilidades y dividiéndolo en componentes más manejables.

¿Cómo estaba estructurado el código original?

El código inicial contenía varias responsabilidades en una sola clase llamada PaymentProcessor. Estas responsabilidades incluían:

Validación de datos del cliente
Validación de los datos de pago
Procesamiento del pago con Stripe
Envío de notificaciones (email o SMS)
Registro de la transacción en logs

Este enfoque infringe el principio SRP, ya que una sola clase está encargada de múltiples tareas, lo que hace difícil mantener y escalar el código.

¿Cómo refactorizar el código aplicando SRP?

El primer paso fue identificar las distintas responsabilidades dentro de la clase. Se encontraron cuatro bloques importantes de responsabilidades:

Validación de datos del cliente.
Validación de datos del pago.
Procesamiento del pago.
Notificación y logging de transacciones.

¿Cómo organizar las nuevas clases?

1. ¿Cómo separar la validación de datos del cliente?

Se creó una clase CustomerValidation con el método validate, encargado exclusivamente de validar los datos del cliente, como nombre y contacto. El código de validación fue extraído de la clase PaymentProcessor y movido aquí.

2. ¿Cómo manejar la validación del pago?

Al igual que en la validación del cliente, se creó una clase PaymentDataValidator, encargada de validar los datos de pago, como la fuente de pago (por ejemplo, si se provee una tarjeta o token válido).

3. ¿Cómo procesar el pago sin romper SRP?

El procesamiento de pago es una responsabilidad que corresponde a la interacción con la API de Stripe. En este caso, se mantuvo esta lógica en una clase llamada StripePaymentProcessor, asegurando que solo procese pagos.

4. ¿Cómo gestionar las notificaciones?

Se creó una clase Notifier, que maneja el envío de notificaciones, ya sea por email o SMS. Esto ayuda a aislar la lógica de notificaciones del resto del código, permitiendo cambios futuros sin afectar otras partes.

5. ¿Cómo registrar logs de transacciones?

Se añadió una clase TransactionLogger dedicada al registro de las transacciones. Esta clase se encarga de capturar información de la transacción y guardarla en los logs del sistema.

¿Cómo coordinar todas estas clases?

Se unieron todas estas clases bajo una nueva entidad PaymentService, que orquesta la interacción entre ellas. Esta clase permite coordinar la validación, procesamiento, notificaciones y registro de transacciones de manera eficiente y con SRP.

¿Cómo se manejan los errores y excepciones?

Cada clase maneja sus propias excepciones, asegurando que las validaciones levanten errores específicos cuando los datos son incorrectos. Además, se agregó manejo de excepciones con try-except para capturar fallas en el procesamiento de pagos, lo que permite gestionar errores de manera controlada.

Frank Casanova

student•

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 :)

Axel Díaz

student•

De hecho, considero que no está bien tener un try/except evaluando englobando varias validaciones. En el momento que salte la excepción no vas a saber a ciencia cierta cuál fue explícitamente.

La forma correcta es hacer que cada validate tenga una excepción específica. Por ejemplo, el customer_validator debe retornar un CustomerValueError. Y al momento de hacer el try hacer algo como:

try:
    self.customer_validator.validate(customer_data)
except CustomerValueError as e:
    raise e
```De esta forma se hace un except específico y tampoco tienes el típico try evaluando un gran bloque de código.

Emilio Nicolás Mendoza Patti

student•

Yo creo que esta bien lo que dice el comentario porque funcionaria como un pasamanos porque el raise de las clases que hacen validate suben hasta el unico exept entonces si sabriamos de que parte es el error

Entonces esta parte podria ser asi:

Ahora mi duda es que opinan de esto:

Francisco Suriel Lino Cadena

student•

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.

Leonardo daniel Gutierrez Medellin

student•

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:

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.

Mariano Gobea Alcoba

student•

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.

Ray Trápala

student•

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

Gabriel de Jesus Chirinos Marcano

student•

Podrias delegar el manejo de errores como otra responsabilidad.

David Agudelo

student•

TIP:

si tienen la extensión de GIT en VS-Code, y quieren comparar rápidamente los archivos vistos en clase

Before.py Vs initial_code.py, Sólo tienen que copia y pegar el contenido de un archivo sobre el otro y GIT les va a marcar en: - VERDE : Cambios (+) - ROJO : Cambios (-)

Ray Trápala

student•

No sé si se ve más adelante pero, la clase

class ``PaymentDataValidator

no sería más una función disfrazada de clase?, es correcto solo tener un método para una clase?

Eduardo José Álvarez

Team Platzi•

no hay ningún problema con que sea una clase, también puedes utilizar funciones para las validaciones. Se podría declarar que los validadores son Callable y de igual forma se pueden definir dentro de la clase principal. Dejan de ser clases y convertirse en funciones pero cumplen el mismo propósito

Cesar Augusto Mora Castilo

student•

Al revisar el código refactorizado se ve que todas las nuevas clases solo tienen un método declarado, ya que así cumplen con el principio de responsabilidad única y queda modularizado el código como se buscaba.

Se aplica la POO al 100%.

Osnayder Severiche Urda

student•

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.

Adrián Millán

student•

Hola, una duda, que propósito tiene implementar un bloque try except, si en el except solamente se levanta la excepción con el 'raise e' ¿el funcionamiento no sería exactamente el mismo a que si no se tuviera el try except? ya que en ambos casos se levanta la excepción sin agregar ninguna otra funcionalidad.

Diego Castro

student•

El decorador @dataclass en Python simplifica la creación de clases que son principalmente contenedores de datos. Al aplicarlo a una clase, Python genera automáticamente métodos especiales como __init__, __repr__, __eq__, y otros, basándose en las variables de instancia que defines. Esto reduce la cantidad de código boilerplate que necesitas escribir y mejora la legibilidad.

Por ejemplo, al usar @dataclass, puedes crear una clase de forma más sencilla:

from dataclasses import dataclass

@dataclass
class Product:
    name: str
    price: float

Esto crea automáticamente el método __init__ y otros para la clase Product, facilitando su uso.

cristian rojas

student•

Mi pregunta es un poco más enfocada de cara a saber hasta dónde es bueno separar esas funciones, o cómo determinar cuál es ese límite inferior para decir: 'Estas estarían de manera independiente' o 'Es necesario dejarlas juntas'. ¿Hay alguna guía de cara a eso? ¿O algún estándar o alguna norma?

José Alexander Márquez Rivera

student•

¿Por qué a la única clase que no se le puso el decorador @dataclass fue a la clase Notifier?

Samuel Steven Bernal Martínez

student•

Me tardé 2 horas en esta clase pero lo entendí todo! Se que para quienes vamos iniciando puede parecer abrumador, pero dense el tiempo de leer con calma, preguntar a la IA como guia, no la respuesta, buscar tutoriales y entender que hace cada cosa paso por paso!

Mario Alexander Vargas Celis

student•

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.


class Order:

&#x20;   def \_\_init\_\_(self, order\_id, items):

&#x20;       self.order\_id = order\_id

&#x20;       self.items = items



&#x20;   def calculate\_total(self):

&#x20;       total = sum(item\['price'] \* item\['quantity'] for item in self.items)

&#x20;       return total



&#x20;   def save\_to\_database(self):

&#x20;       print(f"Saving order {self.order\_id} to database")



&#x20;   def send\_confirmation\_email(self):

&#x20;       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.


class Order:

&#x20;   def \_\_init\_\_(self, order\_id, items):

&#x20;       self.order\_id = order\_id

&#x20;       self.items = items



class OrderCalculator:

&#x20;   @staticmethod

&#x20;   def calculate\_total(order: Order):

&#x20;       total = sum(item\['price'] \* item\['quantity'] for item in order.items)

&#x20;       return total



class OrderRepository:

&#x20;   @staticmethod

&#x20;   def save(order: Order):

&#x20;       print(f"Saving order {order.order\_id} to database")



class EmailService:

&#x20;   @staticmethod

&#x20;   def send\_confirmation\_email(order: Order):

&#x20;       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.


\# Crear el pedido

order = Order(order\_id=123, items=\[

&#x20;   {"name": "Product A", "price": 10, "quantity": 2},

&#x20;   {"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.

Osnayder Severiche Urda

student•

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.

César Ernesto Rivas Martínez

student•

No me hace sentido poner esto o sus equivalentes:


    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

Camilo Taborda

student•

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

César Ernesto Rivas Martínez

student•

no pierdas el enfoque del curso, el curso no es "hacer una pasarela de pago con python" el curso es patrones de dise;o y su enfoque es saber que no es buena practica y como arreglarlo, por eso sientes que es solo "copiar y pegar", porque sino verias como lo hace mal y luego como lo arregla, se volveria largo, innecesariamente, espero lo hayas seguido viendo y sino pues te míratelo que vale mucho la pena saber esto

Jose Enrique Marquez

student•

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.

Jose Enrique Marquez

student•

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.

Jose Enrique Marquez

student•

Si se fijan en el minuto 15:58 se agrega un StripeError para capturar un error en el proceso pero si falla otra cosa no se captura, ojo mi observación es para las personas que estan tomando la clase y quieran ir mas alla para mejorar su código no para el video en si.

Jose Enrique Marquez

student•

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