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.