The Chain of Responsibility Pattern (Behavioral) ©SoftMoore ConsultingSlide 1

Motivation Consider a context-sensitive help system for a graphical user interface. The object that ultimately provides the help isn’t known explicitly to the object (e.g., a button) that initiates the help request. We can use a chain of objects to decouple the senders from the receivers. The request gets passed along the chain until one of the objects handles it. Each object on the chain shares a common interface for handling requests and for accessing its successor on the chain. ©SoftMoore ConsultingSlide 2

Chain of Responsibility Pattern Intent: Avoid coupling the sender of a request to its receiver by giving more than one object a chance to handle the request. Chain the receiving objects and pass the request along the chain until an object handles it. Applicability: Use Chain of Responsibility when –more than one object may handle a request, and the handler isn’t known a priori. The handler should be ascertained dynamically at runtime. –you want to issue a request to one of several objects without specifying the receiver explicitly. –the set of objects that can handle a request should be specified dynamically. ©SoftMoore ConsultingSlide 3

Chain of Responsibility Pattern (continued) ©SoftMoore ConsultingSlide 4 Client Structure ConcreteHandler1 handleRequest() Handler handleRequest() ConcreteHandler2 handleRequest() successor

Chain of Responsibility Pattern (continued) Participants Handler –defines an interface for handling requests. –(optional) implements the successor link. ConcreteHandler –handles requests that it is responsible for. –can access its successor. –if it can handle the request, it does so; otherwise it forwards the request to its successor. Client –initiates the request to a ConcreteHandler object on the chain. ©SoftMoore ConsultingSlide 5

Chain of Responsibility Pattern (continued) Collaborations: When a client issues a request, the request propagates along the chain until a ConcreteHandler object takes responsibility for handling it. ©SoftMoore ConsultingSlide 6 : ConcreteHandler2: Client: ConcreteHandler1 handleRequest()

Chain of Responsibility Pattern (continued) Consequences Reduced coupling. The pattern frees an object from knowing which other object will handle a request. Both the receiver and the sender have no explicit knowledge of each other. Added flexibility in assigning responsibilities to objects. You can change the chain at run-time, and you can use subclassing to specialize handlers statically. Receipt isn’t guaranteed. Since a request has no explicit receiver, it can fall off the end of the chain without ever being handled. A request can also go unhandled when the chain is not configured properly. ©SoftMoore ConsultingSlide 7

Chain of Responsibility Pattern (continued) Implementation Two possible ways to implement the successor chain –define new links (e.g., in Handler) –use existing links (e.g., parent link in a composite) Allowing multiple handlers for the same request –a request can have zero, one, or several handlers in the chain The chain does not have to be linear; e.g., when using the parent link in a composite ©SoftMoore ConsultingSlide 8

Chain of Responsibility Pattern (continued) Implementation (continued) Representing requests –a “hard-coded” operation invocation convenient and safe permits only a fixed set of requests to be forwarded –request code (e.g., an integer constant or string) flexible, but less type-safe requires conditional statements for handling the request based on its code –use separate request objects ©SoftMoore ConsultingSlide 9

Chain of Responsibility Pattern in Java: Web Application Filters Filters can be used in a web application to intercept, examine, and possibly transform requests or responses associated with servlets, JSP pages, HTML pages, etc. Think of filters as a chain of steps that requests and responses must go through before reaching a servlet, JSP page, or HTML page. The same chain is traversed in reverse order before returning a response to the client (usually a browser). ©SoftMoore ConsultingSlide 10

Using Filters in Web Applications Filters can be used to query the request and act accordingly block the request/response from passing any further or reroute it to a different destination modify the request headers and data, providing a customized version of the request modify the response headers and data, providing a customized version of the response. ©SoftMoore ConsultingSlide 11

Filters in Action ©SoftMoore ConsultingSlide 12 Filter 1 HTML Page Filter 2Servlet Client (browser) HTTP Request HTTP Response Server Client (browser) HTTP Request HTTP Response

Possible Applications of Filters Authentication – blocking requests based on user identity. Logging and auditing – tracking users of a web application. Image conversion – scaling maps, and so on. Data compression – making downloads smaller. Localization – targeting the request and response to a particular locale. Transformations of XML content – targeting web application responses to more than one type of client. ©SoftMoore ConsultingSlide 13

Example: Logging User Access package com.softmoore.filters; import java.util.Date; public class LoggingFilter implements Filter { private FilterConfig filterConfig = null; public void init(FilterConfig filterConfig) throws ServletException { this.filterConfig = filterConfig; } public void destroy() { this.filterConfig = null; } ©SoftMoore ConsultingSlide 14

Example: Logging User Access (continued) public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws ServletException, IOException { HttpServletRequest req = (HttpServletRequest) request; String message = req.getRemoteHost() + " accessed " + req.getRequestURL() + " on " + new Date() + "."); filterConfig.getServletContext().log(message); chain.doFilter(request,response); } ©SoftMoore ConsultingSlide 15

Example: Logging User Access (continued) In the deployment descriptor ( web.xml )... LoggingFilter com.softmoore.filters.LoggingFilter loggingFilter /admin/*... ©SoftMoore ConsultingSlide 16

Chain of Responsibility in Java AWT 1.0 The original version of Java AWT used the Chain of Responsibility pattern for event handling – the component where the event occurred could handle the event and/or pass it along to its container component, which could handle it and/or pass it along to its container. In Java 1.1 the AWT event model changed from the Chain of Responsibility pattern to the Observer pattern. –more efficient easier to ignore low-level events such as mouse movements –more flexible easier for non-GUI objects to handle events since handlers were not required to have a common superclass ©SoftMoore ConsultingSlide 17

Chain of Responsibility in Android Android uses the Chain of Responsibility pattern for event handling. UI components that are event sources have public callback methods that are called by the Android framework when the respective action occurs on that object. Events are dispatched starting at the top object in the view hierarchy and then down the hierarchy until they reach the appropriate destination. Most callback methods return a boolean value to indicate whether or not the event has been “consumed”. Slide 18©SoftMoore Consulting

Chain of Responsibility in Android (continued) The callback method returns true to indicate that the event has been handled (consumed) and that propagation of the event should stop at that point. Returning false indicates that the event has not been handled and that propagation should continue to other listeners in the hierarchy. Slide 19©SoftMoore Consulting

Related Patterns Chain of Responsibility is often applied in conjunction with Composite, where, a component’s parent can act as its successor. ©SoftMoore ConsultingSlide 20

References Chain-of-responsibility pattern (Wikipedia) Chain of Responsibility Pattern (Object-Oriented Design) Follow the Chain of Responsibility (David Geary, JavaWorld) BadInputFilter revisited (John Moore, JavaWorld) ©SoftMoore ConsultingSlide 21