Chain of Responsibility

Chain of Responsibility Concepto: Permite establecer una cadena de objetos receptores a través de los cuales se pasa una petición formulada por un objeto emisor. Cualquiera de los objetos receptores puede responder a la petición en función de un criterio establecido.

Chain of Responsibility. Permite establecer una cadena de objetos receptores a través de los cuales se pasa una petición formulada por un objeto emisor. Cualquiera de los objetos receptores puede responder a la petición en función de un criterio establecido.

Propósito

Evita acoplar el emisor de una petición a su receptor, dando a más de un objeto la posibilidad de responder a la petición. Encadena los objetos receptores y pasa la petición a través de la cadena hasta que es procesada por algún objeto.

Motivación

La idea de este patrón es desacoplar a los emisores y a los receptores dándole a varios objetos la posibilidad de tratar una petición, que se pasa a través de una cadena de objetos hasta que es procesada por alguno de ellos.

Para reenviar la petición a lo largo de la cadena, garantizando que los receptores permanezcan implícitos, cada objeto de la cadena comparte una interfaz común para procesar peticiones y para acceder a su sucesor en la cadena.

Aplicabilidad

Usar Chain of Responsability cuando:

• Hay más de un objeto que puede 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.

Estructura

Una estructura de objetos típica podría parecerse a ésta:

Participantes

• Manejador*: Define una interfaz para tratar las peticiones. Opcionalmente, implementa el enlace al sucesor.
• Manejador Concreto: Trata las peticiones de las que es responsable. Puede acceder a su sucesor. Si el ManejadorConcreto puede manejar la petición, lo hace; en caso contrario la reenvía a su sucesor.
• Cliente: Inicializa la petición a un objeto ManejadorConcreto de la cadena.

Colaboraciones

Cuando un cliente envía una petición, ésta se propaga a través de la cadena hasta que un

objeto Manejador Concreto se hace responsable de procesarla.

Consecuencias

• Reduce el acoplamiento: Libera a un objeto de tener que saber que otro objeto maneja una petición. Ni el emisor ni el receptor se conocen y tampoco tienen que conocer la estructura de la cadena. Simplifica las interconexiones entre objetos. En vez de que los objetos mantengan referencias a todos los posibles receptores, solo tienen una única referencia a su sucesor (Ventaja).

• Añade flexibilidad para asignar responsabilidades a objetos : Se pueden añadir o cambiar responsabilidades para tratar una petición modificando la cadena en tiempo de ejecución (Ventaja).
• No se garantiza la recepción: Dado que las peticiones no tienen un receptor explícito, no hay garantía de que sean manejadas (la petición puede alcanzar el final de la cadena sin haber sido procesada). Una petición también puede quedar sin tratar cuando la cadena no está configurada correctamente (Desventaja).

Patrones relacionados

Este patrón se suele aplicar conjuntamente con el Patrón Composite, en el que los padres de los componentes pueden actuar como sucesores.

Fuentes

• Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides. Patrones de Diseño.Elementos de software orientado a objetos reutilizable, 1995.