1. Chain of Responsibility Pattern Gof pp. 223-232Yuyang Chen

2. Chain of Responsibility Pattern

3. Intent Intent Avoid coupling sender of request to its receiver by giving more than one object chance to handle request. Chain receiving objects and pass request along until an object handles it. Avoid coupling sender of request to its receiver by giving more than one object chance to handle request. Chain receiving objects and pass request along until an object handles it.

4. Chain of Responsibility Pattern Motivation: Motivation: Book Example – Consider context-sensitive help for graphical user interface Book Example – Consider context-sensitive help for graphical user interface Let’s say user clicks on a help button – help provided depends on the button clicks Let’s say user clicks on a help button – help provided depends on the button clicks Help request is handled by one of several user interface objects, but which one depends on context and specificity of available help. Help request is handled by one of several user interface objects, but which one depends on context and specificity of available help. Problem is that object that provides help isn’t known by the object that request help. Problem is that object that provides help isn’t known by the object that request help.

5. Chain of Responsibility Pattern Description Description Decouple senders and receivers by giving multiple objects (in a set order) a chance to handle a request. Request passed until an object handles it. Decouple senders and receivers by giving multiple objects (in a set order) a chance to handle a request. Request passed until an object handles it. 1 st object in chain receives request – either handles it or forwards to next object in chain. 1 st object in chain receives request – either handles it or forwards to next object in chain. Object that makes request has no explicit knowledge of who will handle it – request has an implicit receiver. Object that makes request has no explicit knowledge of who will handle it – request has an implicit receiver.

6. Chain of Responsibility Pattern Request! Request Handled!

7. Chain of Responsibility Pattern Structure Structure

8. Chain of Responsibility Pattern Participants: Handler – defines interface for handling requests. Can also implement successor link Handler – defines interface for handling requests. Can also implement successor link ConcreteHandler – handles requests it is responsible for; otherwise forwards requests to successor. ConcreteHandler – handles requests it is responsible for; otherwise forwards requests to successor. Client – initiates request to a ConcreteHandler in the chain. Client – initiates request to a ConcreteHandler in the chain.

9. Chain of Responsibility Pattern Use Chain of Responsibility when: Use Chain of Responsibility when: More than 1 object may handle a request, and handle isn’t known beforehand. More than 1 object may handle a request, and handle isn’t known beforehand. Want to issue request to one of several objects without specifying receiver explicitly. Want to issue request to one of several objects without specifying receiver explicitly. Set of objects that can handle a request should be specificed dynamically Set of objects that can handle a request should be specificed dynamically

10. Chain of Responsibility Pattern CONSEQUENCES Benefits: Benefits: Decoupling of senders and receivers Decoupling of senders and receivers Added flexibility Added flexibility Sender doesn’t need to know specifically who the handlers are Sender doesn’t need to know specifically who the handlers are Potential Drawbacks: Potential Drawbacks: Client can’t explicity specify who handles a request Client can’t explicity specify who handles a request No guarantee of request being handled (request falls off end of chain) No guarantee of request being handled (request falls off end of chain)

11. Chain of Responsibility Pattern Implementation How to implement the successor chain? How to implement the successor chain? Define new links (in Handler or ConcreteHandler) Define new links (in Handler or ConcreteHandler) Use existing links Use existing links (such as the parent references from the Composite pattern) (such as the parent references from the Composite pattern)

12. Chain of Responsibility Pattern Sample Code: Sample Code: class HelpHandler { public: HelpHandler(HelpHandler* s) : _successor(s) { } virtual void HandleHelp(); private: HelpHandler* _successor; }; void HelpHandler::HandleHelp() { if(_successor) { _succeessor->HandleHelp(); }

13. Chain of Responsibility Pattern Representing Requests Representing Requests Request can be hard-coded operation. This is convenient and safe, but can only forward fixed set of requests that Handler class defines. Request can be hard-coded operation. This is convenient and safe, but can only forward fixed set of requests that Handler class defines. Can use separate request objects that contain all request parameters; these must have accessor functions that return an identifier for the class Can use separate request objects that contain all request parameters; these must have accessor functions that return an identifier for the class

14. Chain of Responsibility Pattern void Handler::HandleRequest (Request * theRequest) { switch (theRequest->GetKind() ) { case Help: // cast argument ot appropriate type HandleHelp( (HelpRequest*) theRequest); break; case Print: HandlePrint((PrintRequest*) theRequest); // etc... } Subclasses can extend this by overriding HandleRequest to handle only the requests in which the subclass is interested.