Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides
"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." (Gamma, E., R. Helm, R. Johnson, and J. Vlissides. Design Patterns: Elements of Reusable Object-Oriented Software. Reading, MA: Addison-Wesley, 1995)
Consider a context-sensitive help facility for a graphical user interface. The user can obtain help information on any part of the interface just by clicking on it. The help thats provided depends on the part of the interface thats selected and its context; for example, a button widget in a dialog box might have different help information than a similar button in the main window. If no specific help information exists for that part of the interface, then the help system should display a more general help message about the immediate context--the dialog box as a whole, for example. Its clear that a help request is handled by one of several user interface objects; which one depends on the context and how specific the available help is. The object that ultimately provides the help isnt known explicitly to the object (e.g., the button) that initiates the help request. We need a way to decouple the button that initiates the help request from the objects that might provide help information. The Chain of Responsibility pattern defines how that happens. The idea of this pattern is to decouple senders and receivers by giving multiple objects a chance to handle a request. The request gets passed along a chain of objects until one of them handles it. The first object in the chain receives the request and either handles it or forwards it to the next candidate on the chain, which does likewise. Assume the user clicks for help on a button marked "Print." The button is contained in an instance of PrintDialog (ConcreteHandler in the thumbnail), which knows the application object it belongs to. The PrintDialog does not handle the request; it stops at anApplication which can handle it or ignore it. The help system might define a HelpHandler class (Handler in the thumbnail) with a corresponding HandleHelp operation. HelpHandler can be the parent class for candidate object classes, or it can be defined as a mixin class. Then classes that want to handle help requests can make HelpHandler a parent.
This pattern has been used on the following systems: Several class libraries use this pattern to handle user events. The names they use for the Handler class are different; however, the idea is the same: when the user clicks the mouse or presses a key, an event gets generated and passed along the chain. Following are applications that use this pattern: MacApp calls it "Event-Handler." (Apple Computer, Inc., Cupertino, CA. Macintosh Programmers Workshop Pascal 3.0 Reference, 1989.) ET++ calls it "Event-Handler." (Weinand, A., E. Gamma, R. Marty. ET++--An object-oriented application framework in C++. In Object-Oriented Programming Systems, Languages, and Applications Conference Proceedings, pp. 46-57, San Diego, CA, September 1988. ACM Press.) Symantecs TCL library calls it "Bureaucrat." (Symantec Corporation, Cupertino, CA. THINK Class Library Guide, 1993.) NeXTs AppKit calls it "Responder." (Addison-Wesley, Reading, MA. NEXTSTEP General Reference: Release 3, Volumes 1 and 2, 1994.)
Composite pattern
Composite pattern, Chain of Responsibility pattern, behavioral patterns, Gamma patterns, forward requests, object composition, chain, request handler
any system with sets of objects that can handle similar requests
frequent change requests/requirements changeneed to modify object behaviors dynamically without affecting existing objectsneed to provide abstraction between subsystem and clientthere are many related classes that differ only in their behaviorthere is more than one object that may handle a request
increases reuse of classes by de-coupling the interface from the implementationmay reduce compilation dependenciesprovides weak coupling between clients and subsystems
a request for service may be ignored if no objects are configured for the service
Test driver Test.javaSimple implementation of the pattern - Handler class. Handler.javaSimple implementation of the pattern - ConcreteHandler2 class. ConcreteHandler2.javaSimple implementation of the pattern - ConcreteHandler1 class. ConcreteHandler1.javaTest driver testchain.cppSimple implementation of the pattern. chain.h