Design Patterns Simplified - Chain Of Responsibility

I am here to discuss one of the popular behavioral design patterns, called Chain of Responsibility. Before going through its implementation, let’s begin by defining it.

As per GOF guys, Chain of Responsibility pattern is defined as following.

“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.”

Well! Let’s understand what they mean and where this pattern can fit.

It simply means that this pattern is about having workflow kind of setup where any request goes from one to another based on certain logic. Some of the use cases can be as follows.

Leave approval mail from Team lead -> Project Lead -> Delivery Manager -> Director
Support tickets resolution from Level 0 -> Level 1 -> Level 2 -> Level 3
Loan approval form Clerk -> Assist Manager -> Manager
Asset purchase approval from Director -> Vice President -> President
Content approval from Proof Reader -> Editor -> Senior Editor

Another example of this pattern in .NET framework is the execution of catch statements in the try...catch block. Here, each catch block considers the request in the order and pass on to the next, if not able to handle.

Now, let’s see the custom implementation of the pattern. Please have a look at the code map diagram of the demo we have created.

Design patterns

As you can see, Chain of Responsibility pattern has some key components.

Handler -> Interface/abstract class to handle the request and set the successor or next approver link. In the diagram above Approver abstract class does this job.
ConcreteHandler -> Provides the implementation to the hander. Here TeamLead, ProjectLead, DeliveryManager and Director classes have been used for this.
Client -> Creates the request and passes on to the respective concrete handler in the chain. Here Client class is there to serve the purpose.

How Chain of Responsibility pattern works:

Let’s understand this by a demo project we have created.

First, create the Approver abstract class.

abstract class Approver
{
protected Approver NextApprover;
public abstract void ApproveLeave(int numberOfLeaves);
public void SetNextApprover(Approver nextApprover)
{
this.NextApprover = nextApprover;
}
protected abstract bool CanApprove(int numberOfLeaves);
}

As you can see, successor is being set via SetNextApprover method and NextApprover object stores it.

Now, we need to create concrete classes where we will provide the implementation to the abstract methods.

class TeamLead : Approver
{
public override void ApproveLeave(int numberOfLeaves)
{
if (CanApprove(numberOfLeaves))
{
Util.PrintLeaveMesage(this.GetType().Name, numberOfLeaves);
}
else
{
Util.SetNextApproverElsePrint(this, numberOfLeaves);
}
}
protected override bool CanApprove(int numberOfLeaves)
{
if (numberOfLeaves <=3)
{
return true;
}
return false;
}
}
class ProjectLead : Approver
{
public override void ApproveLeave(int numberOfLeaves)
{
//Omitted for simplicity, Same as TeamLead class
}
protected override bool CanApprove(int numberOfLeaves)
{
if (numberOfLeaves > 3 && numberOfLeaves <= 10)
{
return true;
}
return false;
}
}
class DeliveryManager : Approver
{
public override void ApproveLeave(int numberOfLeaves)
{
//Omitted for simplicity, Same as TeamLead class
}
protected override bool CanApprove(int numberOfLeaves)
{
if (numberOfLeaves > 10 && numberOfLeaves <= 15)
{
return true;
}
return false;
}
}
class Director : Approver
{
public override void ApproveLeave(int numberOfLeaves)
{
//Omitted for simplicity, Same as TeamLead class
}
protected override bool CanApprove(int numberOfLeaves)
{
if (numberOfLeaves > 15 && numberOfLeaves <= 20)
{
return true;
}
return false;
}
}

We have also created utility class (Util.cs) to enforce the code reusability and avoid duplication of code. The definition goes as below.

class Util
{
public static void PrintLeaveMesage(string approver, int numberOfLeaves)
{
Console.WriteLine(approver + $" has approved the leave(s) applied for {numberOfLeaves} day(s)");
}
public static void SetNextApproverElsePrint(Approver approver, int numberOfLeaves)
{
if (approver.NextApprover != null)
{
approver.NextApprover.ApproveLeave(numberOfLeaves);
}
else
{
Console.WriteLine("Your leaves require special approval, please contact HR dept.");
}
}
}

As you can see in all the four concrete classes we have given the custom definition of the CanApprove method based on the specification or characteristics of the approver. If any receiver is able to approve, the request ends there else it goes to the next approver in the chain.

In Util class, we are printing the user-friendly messages and setting the next approver.

Now it’s time to setup client. Let put the code for it.

class Client
{
static void Main(string[] args)
{
Console.Title = "Chain of Responsibility Demo";
TeamLead tl = new TeamLead();
ProjectLead pl = new ProjectLead();
DeliveryManager dm = new DeliveryManager();
Director d = new Director();
tl.SetNextApprover(pl);
pl.SetNextApprover(dm);
dm.SetNextApprover(d);
tl.ApproveLeave(3);
tl.ApproveLeave(7);
tl.ApproveLeave(12);
tl.ApproveLeave(17);
tl.ApproveLeave(22);
}
}

And here goes the output of the demo we have developed.

Design patterns

Conclusion

In the article, we have gone through what Chain of Responsibility pattern is, when and how to use it. So, to summarize, it can be used in places where you want to pass on the request to the set of handlers at runtime. You can also download the attached demo project (CORPatternDemo.zip) to go through the full source code referred in the article.

Hope you have liked the article. Look forward to your comments/suggestions.

4 Comments

Join the conversation! Your thoughts help the community grow.

Bhavesh Jadav8y ago
Good explain with example, thanks to share it
- Prakash Tripathi8y ago
  Thanks Bhavesh Jadav for liking the content.
Naresh Singhal8y ago
Nicely explained................
- Prakash Tripathi8y ago
  Thanks Naresh Singhal for liking the content.