Design Patterns part 5 : Chain Of Responsibility Pattern

Chains (Photo by Markus Spiske on Unsplash)

The design pattern that we are going to discuss about today is similar to the above image. With a chain we can decrease its length by cutting off a part or increase its length by adding new parts to the chain. Just like this chain the Chain Of Responsibility design pattern can do operations. If you are new to design patterns, I would recommend you to read the first half of my first Design pattern article by clicking here. Now that introductions are over lets talk about the design pattern.

You all must have real life experience that is similar to this design pattern. For example you all must have made a call to a customer service center. And the automated message will be playing asking to press different buttons depending on the service that you will be needing. And different messages or different customer care workers will answer to your needs. The Chain Of Responsibility Design Pattern also works like a customer care call.

What is Chain of Responsibility

Chain of Responsibility comes under the behavioral design pattern of the gang of 4. This design patter helps to loosely couple the components of the application. So that two components are not entirely depended on each other. We can implement the Chain Of Responsibility like a linked list.

UML Diagram

As seen from the above diagram, the request will be accepted by the handlers and will be passed down to each handlers depending on the condition. Chain or Responsibility can be implemented to do tasks that will do tasks synchronously between the handlers(The results from the previous handler will be used in the next handler) or entirely independent handlers that will do their own tasks according to the specifications.

So first lets look at the implementation of the following scenario, then I will give some more information about this design pattern.

IMPLEMENATATION

Scenario : There is an organization that have employees, and employees can ask for additional budget for the project that there doing. According to the cost, the budget can be approved by either the shift lead, team lead or the manager. If the budget cannot be approved by the manager then the system will say that the budget cannot be approved.

Now lets take a look at the implementation of the above problem. First lets create a budget class. The below code is the implementation of the Budget class.

The budget class will have employee name and the cost for their budget. This class will also have getters and setters.

Now we will need an abstract or interface class that the each components of the chain will implement or extend, these components can be called as handlers. Look at the below code for the implementation of the handler class.

The abstract class will have an instance of itself to hold the pointer to the next successor in the chain(Like linked list) we will be having a setter to set the next handler in the chain and also have an abstract method that will be checking if the budget can be approved or passed to the next handler. Now that we have the base class lets create the classes ShiftLead, TeamLead and Manager which will be extending the above abstract class.

The above classes are going to be our handler classes and each will be checking the budget. If they can approve the budget they will return their approval as a String and if they cannot approve the budget they will pass it on to the next handler. The process is shown below in a simple diagram.

Chain

We will also create another handler which will be the starting point and I will call this BudgetCheck.

Now that we have these classes its time to implement the main method.

The above is the main method for this application. As seen above we are creating instances for the handlers from line number 4 to line number 6. And I am setting the successors from line number 9 to 11 by calling the setSuccessor() method. After that I am creating different budget instances with different costs and then call the BudgetCheck class’s instance bc’s checkEligibility() method. The output will be this;

Output

As you can see from the above output different handlers are printing the value according to the value that is passed. Some of you all must be thinking why do Chain Of Responsibility when we can also do if else statements. Imagine you want to remove ShiftLead from the logic. If you implemented this with if else you will be going into the logic of the code and making changes to it, but by implementing as Design Of Responsibility we simply need to change one line of our code which is, bc.setSuccessor(tl) . We can also add new handlers and remove handlers without touching the core logic.

KEY POINTS

Now that we know the implementation of the Chain Of Responsibility design pattern, lets take a look at some key points.

• Loose coupling : Loose coupling means that, existence of one object is not entirely dependent on the other. This improves the scalability of your project. This implies that a component can be changed without needing to change the whole core code
• Easily add new handlers and change the order : In this design pattern we can easily add new handlers and also change the order of operations depending on our need.
• If there is no handler for a particular response the design pattern will simply ignore it.
• The main advantage of this design pattern is also its main disadvantage, the end developer is able to change the order of the chain.
• This design pattern is implemented in the logger class in the JDK. We can check this by setting the loglevel with setLevel() function and then calling the log() function.

Now that we know about the key points of this design pattern there is one last point to know about, where to use this design pattern. This design pattern can be used in places where a process is based on permission like the system I have implemented above. Another example is a system that will calculate salary according to the position, work hours and also the project that the employee worked on.

The following are the links to my previous articles which will cover the design patterns under the Creational Pattern.

Part 1 : Overview of Design Patterns and Singleton Design Pattern.

Part 2 : Factory Design Pattern

Part 3 : Prototype Design Pattern

Part 4 : Builder Design Pattern

Thanks for reading 😃.

REFERENCES

Click here to go to the GitHub Repository for the above used codes.

This video by Krishantha Dinesh was a huge help in creating this article.

Chain of Responsibility

Chain of Responsibility Design Pattern - GeeksforGeeks

Real-Time Examples of Chain of Responsibility Design Pattern in C#