Chain of Responsibility Design Pattern

Chain of responsibility pattern is used to achieve loose coupling in software design where a request from client is passed to a chain of objects to process them. Then the object in the chain will decide themselves who will be processing the request and whether the request is required to be sent to the next object in the chain or not.

Chain of Responsibility Pattern Example in JDK

Let’s see the example of chain of responsibility pattern in JDK and then we will proceed to implement a real life example of this pattern. We know that we can have multiple catch blocks in a try-catch block code. Here every catch block is kind of a processor to process that particular exception.

So when any exception occurs in the try block, its send to the first catch block to process. If the catch block is not able to process it, it forwards the request to next object in chain i.e next catch block. If even the last catch block is not able to process it, the exception is thrown outside of the chain to the calling program.

Chain of Responsibility Design Pattern Example

One of the great example of Chain of Responsibility pattern is ATM Dispense machine. The user enters the amount to be dispensed and the machine dispense amount in terms of defined currency bills such as 50$, 20$, 10$ etc.

If the user enters an amount that is not multiples of 10, it throws error. We will use Chain of Responsibility pattern to implement this solution. The chain will process the request in the same order as below image.

Note that we can implement this solution easily in a single program itself but then the complexity will increase and the solution will be tightly coupled. So we will create a chain of dispense systems to dispense bills of 50$, 20$ and 10$.

Chain of Responsibility Design Pattern – Base Classes and Interface

We can create a class Currency that will store the amount to dispense and used by the chain implementations.

Chain of Responsibilities Pattern – Chain Implementations

We need to create different processor classes that will implement the DispenseChain interface and provide implementation of dispense methods. Since we are developing our system to work with three types of currency bills – 50$, 20$ and 10$, we will create three concrete implementations.

The important point to note here is the implementation of dispense method. You will notice that every implementation is trying to process the request and based on the amount, it might process some or full part of it.

If one of the chain not able to process it fully, it sends the request to the next processor in chain to process the remaining request. If the processor is not able to process anything, it just forwards the same request to the next chain.

Chain of Responsibilities Design Pattern – Creating the Chain

This is a very important step and we should create the chain carefully, otherwise a processor might not be getting any request at all. For example, in our implementation if we keep the first processor chain as Dollar10Dispenser and then Dollar20Dispenser, then the request will never be forwarded to the second processor and the chain will become useless.

Chain of Responsibilities Design Pattern Class Diagram

Chain of Responsibility Design Pattern Important Points

Client doesn’t know which part of the chain will be processing the request and it will send the request to the first object in the chain. For example, in our program ATMDispenseChain is unaware of who is processing the request to dispense the entered amount.

Each object in the chain will have it’s own implementation to process the request, either full or partial or to send it to the next object in the chain.

Every object in the chain should have reference to the next object in chain to forward the request to, its achieved by java composition.

Creating the chain carefully is very important otherwise there might be a case that the request will never be forwarded to a particular processor or there are no objects in the chain who are able to handle the request. In my implementation, I have added the check for the user entered amount to make sure it gets processed fully by all the processors but we might not check it and throw exception if the request reaches the last object and there are no further objects in the chain to forward the request to. This is a design decision.

Chain of Responsibility design pattern is good to achieve lose coupling but it comes with the trade-off of having a lot of implementation classes and maintenance problems if most of the code is common in all the implementations.

Chain of Responsibility Pattern Examples in JDK

java.util.logging.Logger#log()

javax.servlet.Filter#doFilter()

Thats all for the Chain of Responsibility design pattern, I hope you liked it and its able to clear your understanding on this design pattern.

Comments

Hi Pankaj,
great tutorials. Keep going please, with your tutorials because are very useful and educational.
I have a question however, here it is. How this would work the same but just for 20 and 50 only Monetaries ? any hint?
Thank you

Firstly i would like to thank you for this Wonderful article.
Just a finding from my end, which i would like to share. Please correct me if i am wrong.

I think the else part in all the dispense method is not required. It gives a wrong output.
Say for example; see the following steps
1. Say if i entered 60, it will enter the Dollar50 dispense method and it will print (1 note being dispensed – 50 dollar).
2. as the remainder is !=0, it will go to next dispenser in the chain.

3. Say if i entered 50, it will enter Dollar50 dispense method and it will print ( 1 note being dispensed – 5o dollar)
4. as the remainder is 0, it will enter the else part and it will print again the above content (as shown in point 3).

I did test in my machine and removed the else part, and it works correctly for any number.

In the Dispence method of Dollar50Dispenser, Dollar20Dispenser and Dollar10Dispenser, else part is not required i guess. Request is already getting processed to the next chain dispense if remainder != 0 . Correct me if i am wrong.

And I didnt get the use of always true while loop in the main method. Not required i guess.

Thank you very much Pankaj. The tutorial on Design Patterns was very helpful. I could get a brief overview of Design Patterns and one more good point is that you have taken real world examples to demonstrate. In some part of the tutorial you have mentioned that one design pattern can be combined with the other to make it more efficient, it would be helpful if you post some samples on it. Great work buddy. Thanks a lot.

Mate, once again, check your English! It’s loose coupling. Furthermore, Gaurav, you’re right about only one object handling the request. That would be what’s called a pure implementation. On the other hand, there’s no real problem to let the request go through the entire tree.

Another point, which is not discussed in this article, is that you may set or change the next handler during runtime. You also may not know beforehand which are the handlers that should be used, allowing the client to set them as desired. As an example, you could have many Validator classes which can be called in a certain order. But that depends on the validation. So you apply CoR and make good use out of the possibility of combining different validators ordered in so many different ways.

Suppose you want to validate an email address. You need to check if the e-mail is correctly formed, if it exists, and if contains bad words. To do this job, you may have three different classes, and you can arrange them in any order – so you might as well let the client decide its own priority.

After implementing this design pattern for years, i commonly see that there is repeated code in the concrete classes just like the implementation of your dispense methods. The intent of this design pattern is nice, but dont forget the DRY principle and it is a must in my humble opinion. I always use abstract classes for cor design pattern to eliminate duplicate code.

Good example. I’d like to point out one thing though. The pattern per GoF definition says that ‘Only one object in the chain is supposed to handle a request’. In your example I see handlers($50 and $20) doing the work partially and letting $10 handler do the rest of the job.

Hi.. Nice tutorial.. Just 1 suggestion setNextChain() would have been moved to DispenseChain abstract class instead of keeping DispenseChain as abstract class and overriding setNextChain() in all the concrete classes..

By having setNextChain() as abstract method, we are forcing subclasses classes to provide implementation for that. For example purpose implementation is simple but there might be cases where some logic is involved for this.

Yes if it’s simple as this, we can move it to abstract class. It’s a design decision and should be based on project requirements.

Exception in thread “main” java.lang.NullPointerException
at com.chain.responsibility.dispenser.HundredDollarDispenser.dispense(HundredDollarDispenser.java:26)
at com.chain.responsibility.dispenser.FiftyDollarDispenser.dispense(FiftyDollarDispenser.java:30)
at com.chain.responsibility.dispenser.ATMDispenseChain.main(ATMDispenseChain.java:33)

Popular Categories

Newsletter for You

Don't miss out!

Subscribe To Newsletter

We promise not to spam you. Unsubscribe at any time.

Invalid email address

Thanks for subscribing!

JournalDev is one of the most popular websites for Java, Python, Android, and related technical articles. Our tutorials are regularly updated, error-free, and complete. Every month millions of developers like you visit JournalDev to read our tutorials.

JournalDev was founded by Pankaj Kumar in 2010 to share his experience and learnings with the whole world. He loves Open source technologies and writing on JournalDev has become his passion.