Implementación del Principio de Segregación de Interfaces en Procesadores de Pago

Implementar el principio de segregación de interfaces es clave para mantener el código limpio y flexible en sistemas complejos como un procesador de pagos. En este caso, se abordaron varias mejoras dentro del procesador de pagos que incluyen la creación de métodos específicos para reembolsos y recurrencias, junto con la correcta segregación de las interfaces según las capacidades de cada procesador de pago.

¿Qué cambios se realizaron en el procesador de pagos?

• Se agregaron dos nuevos métodos: reembolso y creación de recurrencias.
• Se implementó un segundo procesador de pagos, el procesador offline, que simula pagos en efectivo. Sin embargo, este procesador no puede realizar reembolsos ni crear recurrencias.
• El método processTransaction fue modificado para no depender del atributo de Stripe, ya que ahora hay múltiples procesadores.

¿Por qué falló la implementación del principio de segregación de interfaces?

El procesador de pagos offline implementaba métodos que no podía usar, como los reembolsos y las recurrencias, lo que violaba el principio de segregación de interfaces. Este principio establece que una clase no debe depender de métodos que no puede implementar o usar.

¿Cómo se corrigió el problema?

• Se crearon dos nuevos protocolos: uno para reembolsos (RefundPaymentProtocol) y otro para recurrencias (RecurringPaymentProtocol).
• Estos protocolos definen exclusivamente los métodos para esas acciones, eliminando la necesidad de que procesadores como el offline implementen métodos que no necesitan.
• Los procesadores que pueden realizar todas las acciones, como Stripe, ahora implementan los tres protocolos: uno para cobros, otro para reembolsos y otro para recurrencias.

¿Qué otros ajustes se hicieron en el servicio?

• Se agregaron atributos opcionales para los procesadores de reembolsos y de recurrencias (RefundProcessor y RecurringProcessor), permitiendo que cada tipo de procesador maneje solamente las acciones que le corresponden.
• Se implementaron validaciones para evitar excepciones en caso de que un procesador no soporte ciertas acciones. Si el procesador no soporta reembolsos o recurrencias, se lanza una excepción con un mensaje claro.

¿Cómo afecta este cambio al procesador de Stripe y al procesador offline?

• En el caso de Stripe, ahora maneja los tres protocolos, permitiendo cobrar, hacer reembolsos y gestionar pagos recurrentes.
• El procesador offline, al no manejar reembolsos ni recurrencias, ya no tiene que implementar esos métodos, cumpliendo con el principio de segregación de interfaces.