Design Patterns -- Chain of Responsibility (CoR)

 1. The intent of the Chain of Responsibility is to avoid coupling the sender of a request to its receiver by giving more than one object a chance to handle the request. To apply this pattern, chain the receiving objects and pass the request along the chain until an object handles it, see pic:

If you use the CoR pattern, remember: (somewhat like " switch - case - default ")

 

• Only one object in the chain handles a request
• Some requests might not get handled

So, in Chain of Responsibility, an object model takes on the job of finding which object can satisfy a client's request, the class diagram:

Chain of Responsibility class diagram

Typically, request handlers are extensions of a base class that maintains a reference to the next handler in the chain, known as the successor. For example, the code:

public abstract class HandlerBase {
         ...
         public void handleRequest(SomeRequestObject sro) {
            if(successor != null)
                  successor.handleRequest(sro);
         }
   }

A concrete extension of HandlerBase might look like this: 


   public class SpamFilter extends HandlerBase {
      public void handleRequest(SomeRequestObject mailMessage) {
         if(isSpam(mailMessage))   { // If the message is spam
            // take spam-related action. Do not forward message.
         }
         else { // Message is not spam.
            super.handleRequest(mailMessage); // Pass message to next filter in the chain.
         }
      }
   }


 

 In my point of view, Chain of Responsibility pass or divides the resiponsibility to the objects in the chain.

It leads to simpler code in both the hierarchy and the client, which is the main advantage of this pattern.