Procesar solicitudes de forma ordenada y flexible es una necesidad frecuente en sistemas de pagos, autenticación y validación de datos. El patrón Chain of Responsibility ofrece exactamente eso: una cadena donde cada eslabón tiene una única responsabilidad y puede aceptar o rechazar la solicitud antes de pasarla al siguiente.

¿Qué es el patrón Chain of Responsibility y cómo funciona?

El Chain of Responsibility es un patrón de diseño de comportamiento que define un flujo de procesamiento de solicitudes a través de distintos manejadores [0:14]. Cada manejador tiene una responsabilidad única y puede aplicar condiciones específicas para determinar si la solicitud es válida o debe ser rechazada.

La estructura se basa en una clase o interfaz llamada Validator que define dos métodos fundamentales [0:36]:

• Set Next: establece el siguiente elemento dentro de la cadena de validaciones.
• Validate: verifica si lo que está llegando es válido o no.

A partir de esta abstracción se crean implementaciones concretas. En el ejemplo de un servicio de pagos, se definen tres validadores específicos [0:52]:

• Validador de monto.
• Validador de tarjeta.
• Validador de fraude.

Cada uno evalúa un aspecto diferente de la solicitud. Si el primero aprueba, pasa al segundo; si el segundo aprueba, pasa al tercero. Si alguno detecta un problema, la cadena se interrumpe y la solicitud se rechaza.

¿Cuándo aplicar la cadena de responsabilidad en un proyecto?

Este patrón es ideal cuando se necesita procesar una solicitud a través de una serie de pasos [1:04]. No se limita a pagos: cualquier sistema que requiera autenticación es un caso de uso claro. Por ejemplo, se valida que el usuario esté autenticado, que esté autorizado y que cumpla con los requerimientos para solicitar una acción dentro del servicio [1:15].

También resulta útil cuando se busca una estructura flexible de validación de datos, donde los pasos puedan agregarse, eliminarse o reordenarse sin afectar el resto del flujo.

¿Cómo se implementa paso a paso?

La implementación sigue cuatro pasos claros [1:30]:

• Definir una interfaz o clase abstracta para los manejadores.
• Implementar cada manejador que herede de esa abstracción.
• Configurar la cadena de manejadores estableciendo el orden con Set Next.
• Enviar la solicitud al primer manejador de la cadena.

Cada manejador se encarga de validar la información, decidir si es válida y pasar al siguiente manejador o directamente rechazarla [1:48]. Este enfoque basado en abstracciones permite extender la cadena sin modificar el código existente, respetando el principio de abierto/cerrado.

¿Por qué las abstracciones son clave en este patrón?

Al igual que otros patrones de diseño de comportamiento, el Chain of Responsibility se fundamenta en abstracciones [1:58]. La interfaz Validator actúa como contrato que todos los manejadores deben cumplir. Esto significa que agregar un nuevo tipo de validación, por ejemplo un validador de límite diario, solo requiere crear una nueva clase que implemente la misma interfaz y conectarla a la cadena.

Esta separación de responsabilidades hace que cada validador sea independiente, fácil de probar y reutilizable en diferentes contextos del sistema.

¿Qué feature modificarías dentro de un servicio de pagos para aplicar este patrón? Comparte tu idea en los comentarios.