Difference between revisions of "Chain of Responsibility"

From CDOT Wiki
Jump to: navigation, search
Line 38: Line 38:
 
*'''Broken Chain'''
 
*'''Broken Chain'''
 
**Sometimes we could forget to include in the implementation of the handleRequest method the call to the successor, causing a break in the chain. The request isn’t sent forward from the broken link and so it ends up unhandled.  
 
**Sometimes we could forget to include in the implementation of the handleRequest method the call to the successor, causing a break in the chain. The request isn’t sent forward from the broken link and so it ends up unhandled.  
 +
  
 
----
 
----
Line 52: Line 53:
 
**If it can handle the request it does so, otherwise it sends the request to its successor
 
**If it can handle the request it does so, otherwise it sends the request to its successor
 
* '''Client''' - sends commands to the first object in the chain that may handle the command
 
* '''Client''' - sends commands to the first object in the chain that may handle the command
 +
  
 
----
 
----
  
 
== Code Examples ==
 
== Code Examples ==
 +
 +
----
 +
 
=== Java Example ===
 
=== Java Example ===
 +
Some Code.....
  
 
----
 
----

Revision as of 21:10, 2 April 2007


Chain of Responsibility (Behavioral Pattern)

  • The Chain of Responsibility pattern uses a chain of objects to handle a request, which is typically an event. Objects in the chain forward the request along the chain until one of the objects handles the event. Processing stops after an event is handled.

CoR1.jpg


Purpose

  • Is to 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.



Applicability

Here are a few situations when using the Chain of Responsibility is more effective:

  • More than one object can handle a request
  • The handler is not known in advance
  • The handler should be determined automatically
  • It’s wished that the request is addressed to a group of objects without explicitly specifying its receiver
  • The group of objects that may handle the request must be specified in a dynamic way



Drawbacks

  • Unhandled requests
    • Unfortunately, the Chain doesn't guarantee that every command is handled, which makes the problem worse, since unhandled commands propagate through the full length of the chain, slowing down the application. One way to solve this is by checking if, at the end of the chain, the request has been handled at least once, otherwise we will have to implement handlers for all the possible requests that may appear.
  • Broken Chain
    • Sometimes we could forget to include in the implementation of the handleRequest method the call to the successor, causing a break in the chain. The request isn’t sent forward from the broken link and so it ends up unhandled.



UML Diagram

CoR UML.jpg


The role of every class:

  • Handler - defines an interface for handling requests
  • ConcreteHandler:
    • handles the requests it is responsible for
    • If it can handle the request it does so, otherwise it sends the request to its successor
  • Client - sends commands to the first object in the chain that may handle the command



Code Examples


Java Example

Some Code.....


C# Example

Our command will be a PhoneCall class with one method "Converse()" which is our command.

C Caller.GIF

Command handler will be a person.

C handler.gif

C RequestCode.gif

This is how we would implement our chain of responsibility:

C main.GIF

And this would be re result:

  • Father: Hey Mother! Pick up the phone!
  • Mother: Hey Son! Pick up the phone!
  • Son: Hey Daughter! Pick up the phone!
  • Daughter: Hello?
  • Hello. This is ACME Movie Rentals with an important message.




External Links

  • External Links


--Djeyarat 15:49, 2 April 2007 (EDT)