Please enable JavaScript.
Coggle requires JavaScript to display documents.
Chain of Responsibility (Implementation (Connecting Successors - Default…
Chain of Responsibility
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.
Implementation
Connecting Successors - Default Implementation of HandleRequest can simply forward request to successor. If a concrete handler does want to handle a request, it can just rely on default implementation, if not, it can subclass and handle
Representing Requests - Can be a hard coded invocation which makes it less flexible or can be an integer code that identifies type of request but requires a lot of conditional handling. A request object can encapsulate the different parameters and subclassing can be used to handle different parameters
Implementing the successor chain Can be handled by defining new links or by using links to existing objects
Motivation
Sometimes the object that makes a request does not know which object should handle it. This can be handled by decoupling the sender from the receiver by using an intermediate set of objects.
The objects are chained, i.e any object knows about its successor. Each object in the chain either handles the request or passes it on to its successor
-
Applicability
You want more than one object to handle the request and you don't want to explicitly specify the receiver
-
More than one object can handle the request and the object to handle this request is not known apriori
Key Objects
Concrete Handler
-
If handler can handle the request, it will if not it passes it on to successor
-
-
-
Consequences
-
Receipt isn't guaranteed - Can forget to add a handler or request can "fall off" chain without being handled
Reduced Coupling - Sender and receiver need not each other. Each handler just needs to know its successor. Client does not need to maintain list of all receivers
-