» Avoid coupling the sender of a request to its receiver by giving more than one object a chance to handle the request!

Transcription

1 Chain of Responsibility Pattern Behavioural! 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! ChainResp-1

2 Motivation! Example: a context sensitive help facility on a graphical interface» User obtains help information by clicking on any part of the interface!» The help that is provide is context dependent! > Button in a dialog box has different information than a button in the main window! > If no specific help exists, then more general help information is displayed! About a dialog box if nothing for button in a dialog box ChainResp-2

3 Motivation 2! Problem» The object that provides the help is not known explicitly to the object that initiates the request! Solution» 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! ChainResp-3

4 Example Chain of Responsibility! aprintbutton handler anokbutton handler asavedialog handler aprintdialog handler anapplication handler ChainResp-4

5 Example Architecture! handler HELP_HANDLER + handlehelp canhandle: BOOLEAN handler.handlehelp APPLICATION WIDGET canhandle showhelp ~canhandle handler.handlehelp DIALOG BUTTON handlehelp showhelp ChainResp-5

6 Abstract Architecture! successor HANDLER + handlerequest canhandle: BOOLEAN CLIENT CONCRETE_HANDLER_1 handlerequest CONCRETE_HANDLER_2 handlerequest ChainResp-6

7 Participants! Handler» Defines an interface for handling requests!» Implements the successor link (optional)! ConcreteHandler» Handles requests for which it is responsible!» Can reference its successor!» Handles request if it can! > Otherwise passes the request to its successor! Client» Initiates the request to a ConcreteHandler! ChainResp-7

8 Applicability! More than one object may handle a request and the handler is not known a priori Want to issue a request to one of several objects without specifying the receiver explicitly The specific object that can handle a request should be specified dynamically ChainResp-8

9 Consequences Reduced coupling! Frees an object from knowing which other object handles a request An object only has to know a request could be handled Receiver and sender have no explicit knowledge of each other An object does not have to know the structure of the chain of responsibility ChainResp-9

10 Consequences Added Flexibility! Added flexibility in distributing / assigning responsibilities among a set of objects Can add or change responsibilities for handling a request by changing the chain of responsibility Can combine with sub-classing to statically specialize handlers ChainResp-10

11 Consequences Receipt is not Guaranteed! Since a request has no explicit receiver, there is no guaranteed it will be handled» The request can fall off the end of the chain!» The chain may be configured incorrectly! ChainResp-11

12 Related Patterns! Often applied in conjunction with Composite» A componentʼs parent can act as its successor! ChainResp-12

13 Chain of Responsibility in Java API! When we write a command for a java.awt.component to appear on the screen, we use component.setvisible For this to succeed, the container of component must itself be made visible, and so must its container, etc. In IBMʼs Visual Age implementation component.setvisible method calls a method on its parent component that calls on its parent, etc.» This is a chain of responsibility for making objects visible!» The client code is shielded from this chain and only calls setvisible on the first component! ChainResp-13