Chain of Responsibility
From CSSEMediaWiki
(Difference between revisions)
| Line 5: | Line 5: | ||
== Intent == | == Intent == | ||
| − | Avoid coupling between the request sender and receiver by introducing more than one | + | Avoid coupling between the request sender and receiver by introducing more than one object to handle the request. |
== When to use it (Applicability) == | == When to use it (Applicability) == | ||
| − | * If there is more than one | + | * If there is more than one object that could handle the request, and the handler isn't known until run-time |
| − | * If a request needs to be issued to several objects without | + | * If a request needs to be issued to several objects without specifying an explicit receiver |
| − | * The handlers for the request only | + | * The handlers for the request are only specified at run-time (dynamically) |
== How it works (Structure) == | == How it works (Structure) == | ||
| Line 19: | Line 19: | ||
* Handler | * Handler | ||
** defines the interface for request handling | ** defines the interface for request handling | ||
| − | ** | + | ** implements the successor link (optional) |
* ConcreteHandler | * ConcreteHandler | ||
** handles the actual request | ** handles the actual request | ||
| − | ** | + | ** provides access to its successor |
| − | ** | + | ** handles the request if it can, otherwise the request is forwarded to the successor |
* Client | * Client | ||
| Line 31: | Line 31: | ||
== Benefits and Drawbacks (Consequences) == | == Benefits and Drawbacks (Consequences) == | ||
| − | * Reduced coupling. Since no explicit handles are specified, the coupling between client and request | + | * Reduced coupling. Since no explicit handles are specified, the coupling between the client and request handler is hugely reduced. |
| − | * | + | * Added flexibility on assigning object responsibility. Flexibility in distributing responsibility is increased. By using different handler objects, the handling of the request can be assigned to different objects (handlers) at run time, which could also give different behaviours. |
| − | * (Drawback) | + | * (Drawback) There is no guarantee that a request will be handled. |
Revision as of 23:23, 20 July 2009
(This is summarised from GoF design patterns book)
Contents |
Intent
Avoid coupling between the request sender and receiver by introducing more than one object to handle the request.
When to use it (Applicability)
- If there is more than one object that could handle the request, and the handler isn't known until run-time
- If a request needs to be issued to several objects without specifying an explicit receiver
- The handlers for the request are only specified at run-time (dynamically)
How it works (Structure)
- Handler
- defines the interface for request handling
- implements the successor link (optional)
- ConcreteHandler
- handles the actual request
- provides access to its successor
- handles the request if it can, otherwise the request is forwarded to the successor
- Client
- initiates the request
Benefits and Drawbacks (Consequences)
- Reduced coupling. Since no explicit handles are specified, the coupling between the client and request handler is hugely reduced.
- Added flexibility on assigning object responsibility. Flexibility in distributing responsibility is increased. By using different handler objects, the handling of the request can be assigned to different objects (handlers) at run time, which could also give different behaviours.
- (Drawback) There is no guarantee that a request will be handled.
