Este patrón permite pasar solicitudes a través de una cadena de manejadores hasta que uno de ellos la maneja, evitando que un solo objeto se apodere de la solicitud. Se usa cuando varios objetos pueden manejar una solicitud y el manejador no se conoce de antemano. El cliente genera solicitudes que pasan a través de la cadena de manejadores específicos hasta que uno la procesa. Esto reduce el acoplamiento y añade flexibilidad para asignar responsabilidades dinámicamente.

1. Patrón de Comportamiento
Chain of Responsibility
Autores
Hegykozi, Hernán Javier
González, Javier

2. Chain of Responsibility
• Propósito
• Motivación, Aplicabilidad
• Estructura, Participantes
• Colaboraciones, Consecuencias
• Implementación, Usos conocidos

3. Chain of Responsibility
Propósito
Evitar que el receptor se apodere por completo de la petición, y
dar oportunidades a otros receptores a contestar a la petición.

4. Chain of Responsibility
Motivación
La petición debe ser procesada por los receptores, lo cual quiere
decir que, ésta petición queda al margen del uso exclusivo.
Pretendemos dar una mayor detalle y especificación a las
peticiones generadas. Las peticiones serán filtradas por todos
los receptores a medida que se van generando los resultados
esperados.

5. Chain of Responsibility
Aplicabilidad
Se usa dicho patrón cuando:
– Hay más de un objeto que pueden manejar una petición, y
el manejador no se conoce a priori, sino que debería
determinarse automáticamente.
– Se quiere enviar una petición a un objeto entre varios sin
especificar explícitamente el receptor.
– El conjunto de objetos que pueden tratar una petición
debería ser especificado dinámicamente.

6. Chain of Responsibility
Estructura

7. Chain of Responsibility
Participantes
Cliente: será el encargado de generar las peticiones que hayan
de pasar por el manejador genérico.
Manejador: deberá estar compuesto por un interfaz donde se
vayan a desarrollar las peticiones que genera el cliente.
Manejador específico: tratará la petición que le corresponda del
cliente.

8. Chain of Responsibility
Colaboraciones
Cuando un cliente envía una petición, ésta se propaga a través
de la cadena hasta que un objeto manejador específico se
hace responsable de procesarla.

9. Chain of Responsibility
Consecuencias
 Reducción del acoplamiento
 Ni el receptor ni el emisor se conocen explícitamente. Un objeto sólo
tiene que saber que una petición será manejada.
 Añade flexibilidad para asignar responsabilidades a objetos.
 Las responsabilidades de los mensajes pueden cambiar mediante la
organización del proceso de ejecución.
 No se garantiza la recepción
 Puesto que no existe un receptor específico para los mensajes, éstos
pueden quedarse sin procesar.

10. Chain of Responsibility
Implementación
 Implementación de la cadena sucesoria. Forma de hacerlo:
 Usando nuevos enlaces, con el patrón Composite.
 Usando los enlaces existentes.
 Conexión de los sucesores
 Los propios Manejadores Específicos serán los que se encargarán de
reenviar la petición de forma incondicional. Las referencias deberán
estar definidas.
 Representación de las peticiones
 Uso de paso de parámetros o variables mediante una función
manejadora, o hacer uso de clases.

11. Chain of Responsibility
Usos conocidos
Podemos encontrar implementaciones del patrón hechas sobre:
 Manejadores de eventos sobre usuarios en bibliotecas.
 Editores gráficos.
 Manejadores de ayuda.