Chain of Responsibility

From CSSEMediaWiki
(Difference between revisions)
Jump to: navigation, search
(New page: ''(This is summarised from GoF design patterns book)'' == Intent == Avoid coupling between the request sender and receiver by introducing more than one objects to handle the request. =...)
 
m (Reverted edits by Ebybymic (Talk); changed back to last version by Mujtaba Alshakhouri)
 
(9 intermediate revisions by 5 users not shown)
Line 1: Line 1:
 +
[[Category:Design Patterns]]
 +
[[Category:Behavioural Patterns]]
 
''(This is summarised from GoF design patterns book)''
 
''(This is summarised from GoF design patterns book)''
  
 
== Intent ==  
 
== Intent ==  
  
Avoid coupling between the request sender and receiver by introducing more than one objects to handle the request.
+
Avoid coupling between the request sender and receiver by introducing more than one object to handle the request. The request is passed along a chain of object until one of the objects decides to handle the request.
  
 
== When to use it (Applicability) ==
 
== When to use it (Applicability) ==
  
* If there is more than one objects could handle the request, and handler isn't known until run-time
+
* 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 specify explicit receiver
+
* If a request needs to be issued to several objects without specifying an explicit receiver
* The handlers for the request only be specified at run-time (dynamically)
+
* The handlers for the request are only specified at run-time (dynamically)
  
 
== How it works (Structure) ==
 
== How it works (Structure) ==
Line 17: Line 19:
 
* Handler  
 
* Handler  
 
** defines the interface for request handling
 
** defines the interface for request handling
** implement the successor link (optional)
+
** implements the successor link (optional)
  
 
* ConcreteHandler
 
* ConcreteHandler
 
** handles the actual request
 
** handles the actual request
** provide an access to its successor
+
** provides access to its successor
** handle the request if it can, otherwise the request is forwarded to the successor
+
** handles the request if it can, otherwise the request is forwarded to the successor
  
 
* Client
 
* Client
 
** initiates the request
 
** initiates the request
 +
 +
== Example ==
 +
 +
You can find [http://java.dzone.com/articles/design-patterns-uncovered-chain-of-responsibility here] a nicely explained java code example of the Chain of Responsibility Pattern usage in the real world.
  
 
== Benefits and Drawbacks (Consequences) ==
 
== Benefits and Drawbacks (Consequences) ==
  
* Reduced coupling. Since no explicit handles are specified, the coupling between client and request hanlder is hugely reduced.
+
* Reduced coupling. Since no explicit handles are specified, the coupling between the client and request handler is hugely reduced.
* Adding more flexibility on object responsiblity assigning. Flexiblity in distributing responsibility is increased. By using different handler objects, the handling of the request can be assigned to different object (handler) at run time, which could also give different behaviours.
+
* 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) Request is not guaranteed to be handled.
+
* (Drawback) There is no guarantee that a request will be handled.
 +
 
 +
==Related Patterns==
 +
* [[Composite]]: Chain of responsibility can be used together with [[Composite]] where a component's parent can act as the successor.
 +
 
 +
==See also==
 +
* [[Design patterns]]
 +
 
 +
{{design patterns}}

Latest revision as of 03:08, 25 November 2010

(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. The request is passed along a chain of object until one of the objects decides 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)

Structure - Chain of Responsibility.jpg

  • 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

Example

You can find here a nicely explained java code example of the Chain of Responsibility Pattern usage in the real world.

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.

Related Patterns

  • Composite: Chain of responsibility can be used together with Composite where a component's parent can act as the successor.

See also


Personal tools