Chain of Responsibility José Manuel Domínguez Arroyo Margarita Lozano Pérez Carlos Ignacio Mantecón Nebreda

Propósito Evita acoplar el emisor de una petición a su receptor, dando a más de 1 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 del patrón es desacoplar a los emisores de los receptores, dándole a varios objetos la posibilidad de tratar una petición. La petición se pasa por una cadena de objetos hasta que uno de ellos la procesa.

El caso que tenemos es el de un generador de logs. El sistema detecta un evento del que debe informar que puede ser de varios tipos, pero, el sistema no se va a preocupar de clasificar el mensaje e imprimirlo, sólo se va a limitar a informar. Por ello necesitamos una manera de desacoplar al emisor, el sistema, de los posibles receptores, los distintos generadores de logs.

El primer objeto de la cadena recibe la petición y, o bien la procesa, o bien la envía al siguiente objeto de la cadena, que hará exactamente lo mismo. El objeto que hizo la petición no sabe cuál de los objetos de la cadena va a responder a ella. Se dice que la petición tiene un receptor implícito. Ejemplo Supongamos que el sistema ha enviado un correo electrónico, el generador de logs de se encuentra en una instancia de Logger,. El diagrama ilustra como la petición de imprimir la entrada de log, pasa a través de la cadena.

En este caso la petición no es procesada por DebuggerLogger, y se detiene en Logger, la cual podría procesarla u obviarla. El cliente que dio origen a la petición no sabe cuál es el objeto que finalmente trata la petición

Para reenviar la petición a lo largo de la cadena y para garantizar que los receptores permanecen implícitos, cada objeto de la cadena comparte una interfaz común para procesar peticiones y para acceder a su sucesor en la cadena. En nuestro caso el método message maneja las peticiones.

Aplicabilidad Este patrón debe usarse cuando: Hay más de un objeto que pueden manejar una petición y esa petición no se conoce a priori, sino que se debe de determinar 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

Participantes Manejador (Logger): Define una interfaz para tratar las peticiones Implementa el enlace al sucesor ManejadorConcreto (DebugLogger, Logger, StderrLogger) 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 ManejadorConcreto se hace responsable de procesarla.

Consecuencias Ventajas e inconvenientes de este patrón:  Reduce el acoplamiento.  Añade flexibilidad para asignar responsabilidades a objetos.  No se garantiza la recepción.

Implementación

import java.util.*; abstract class Logger { public static int ERR = 3; public static int NOTICE = 5; public static int DEBUG = 7; protected int mask; protected Logger next; // el siguiente elemento en la cadena public Logger setNext(Logger l) { next = l; return this; } abstract public void message(String msg, int priority); }

class DebugLogger extends Logger{ public DebugLogger(int mask) { this.mask = mask; } public void message(String msg, int priority) { if (priority == mask){ System.out.println("Escribiendo en DEBUG: "+msg); }else{ if (next != null) next.message(msg, priority); } class Logger extends Logger{ public Logger(int mask) { this.mask = mask; } public void message(String msg, int priority) { if (priority == mask){ System.out.println("Escribiendo en "+msg); }else{ if (next != null) next.message(msg, priority); } class StderrLogger extends Logger{ public StderrLogger(int mask) { this.mask = mask; } public void message(String msg, int priority) { if (priority == mask){ System.out.println("Escribiendo en STDERR: "+msg); }else{ if (next != null) next.message(msg, priority); }

class ChainOfResponsibilityExample{ public static void main(String[] args) { // Construimos la cadena Logger l = new DebugLogger(Logger.DEBUG).setNext( new Logger(Logger.ERR).setNext( new StderrLogger(Logger.NOTICE) ) ); l.message("Entrando en function y.", Logger.DEBUG); l.message("paso 1 completado.", Logger.NOTICE); l.message("Ha ocurrido un error.", Logger.ERR); }

Usos conocidos Varias bibliotecas de clases usan este patrón para manejar los eventos de usuario. Aunque usan nombres distintos, la idea es siempre la misma: cuando el usuario hace clic con el ratón o pulsa una tecla, se genera un evento y se pasa a lo largo de la cadena. El framework de editores gráficos Unidraw define objetos que encapsulan peticiones a los objetos Component y ComponentView. Estos objetos se estructuran jerárquicamente, así pueden reenviar interpretaciones de órdenes a su padre, quien a su vez puede reenviarlas, formando una cadena de responsabilidad. ET++ usa una cadena de responsabilidad para tratar la actualización de gráficos. Un objeto gráfico llama a una operación cada vez que quiere actualizarse, pero el objeto no sabe lo suficiente sobre su contexto, por lo tanto la operación debe reenviar la petición.

Patrones Relacionados El patrón Cadena de Responsabilidad se suele aplicar junto con el patrón Composite. En él, los padres de los componentes pueden actuar como sucesores.