Chain Of Responsibility Design Pattern
Start course
3h 59m

In this course, we will learn the concepts of microservice and spring framework with a focus on design patterns.

Learning Objectives

  • Learn about various design patterns

Intended Audience

  • Beginner Java developers
  • Java developers interested in learning how to Build and Deploy RESTful Web Services
  • Java Developers who want to develop web applications using the Spring framework
  • Java Developers who want to develop web applications with microservices
  • Java Developers who wish to develop Spring Boot Microservices with Spring Cloud


  • Basic Java knowledge

Hello, dear friends. In this video, we will examine the chain of responsibility pattern. So, let's begin. The chain of responsibility design pattern is one of the Gang of Four design patterns which creates a chain of receiver objects for a request. The chain of responsibility pattern is a behavioral pattern which is used to avoid coupling the sender of the request to the receiver and gives more than one receiver object the opportunity to handle the request. The chain of responsibility pattern allows a number of classes to attempt to handle a request independently. The receiver objects of the requests are free from the order, and can be used in any order for processing. 

This pattern, decouples sender and receiver objects based on type of request. This pattern defines a chain of receiver objects having the responsibility depending on runtime conditions to either handle a request or forward it to the next receiver on the chain. This pattern helps us avoid coupling of sender and receiver objects of a request and allows us to have more than one receiver as well for the request. In the chain of responsibility, the sender sends a request to a chain of objects. The request can be handled by any object in the chain. A chain of responsibility pattern says that just avoid coupling the sender of a request to its receiver by giving multiple objects a chance to handle the request.

In other words, we can say that normally each receiver contains reference of another receiver. If one object cannot handle the request then it passes the same to the next receiver and so on and so on and so on. So, let's look at the UML of chain of responsibility pattern. In this UML, handler is an interface which will primarily receive the request and dispatch the request to a chain of handlers. It has reference only to the first handler in the chain and does not know anything about the rest of the handlers. Concrete handlers are actual handlers of the request chained in some sequential order. Client is the originator of the request and this will access the handler to handle it. So, let's look at the advantages of this pattern. 

This pattern reduces coupling and it adds flexibility when assigning responsibilities to objects. Chain of responsibility allows a set of classes to act as one. So, let's ask another question. In what scenarios would you use this pattern?  To use this pattern, some conditions must be met. If more than one object can handle a request and the handler is unknown or a request is to be issued to one of several objects and the receiver is not specified explicitly or the set of objects able to handle the request is to be specified dynamically after these conditions have been met, you can select the chain of responsibility pattern.

Now there are two most commonly used examples for this pattern: a log system and an ATM dispenser. In my opinion, the ATM example is better than the log system example, so let's use the ATM example to create a project using the chain of responsibility pattern. First, create a new project and name it chain of responsibility. We can create a class currency that will store the amount. First, we need a property as amount. Now, in the constructer, we will get this as a parameter. Let's add a getter for the amount. Okay, done. Now, we need a base. Interface name will be DispenseChain. We will need two methods. First, setNext, second will be dispense. We need to create different processor classes that will implement the dispense chain interface and provide implementation of dispense methods. We will use 10, 20, and 50 pounds. First one is 10-pound implements dispense chain. Define dispense chain.

Now, we will override methods. Okay, done. Let's go with 20 pound. The last one is 50 pound. Now, we need an ATM dispense chain class to use altogether. We have to start with the largest amount so we will start with 50 pound. Now, define 20, define 10. Now, we need the next chain method. 50 pounds next is must be 20, and 20 lbs. next will be 10. Done. Now, we can use it on the client page. First, define an ATMDispenseChain. Now, we will get value from the user. Now, we need a loop. I think the best loop is the while loop for the situation, amount equal zero.

Now, we need a condition to make sure that the money amount can be divided 10. Now, we will start with 50. Now, we finish because 50 will send us to 20, and 20 will send us to 10 and the program will be finished. Let's try. First, let's try 310. Now, try 170. As you can see our project is a success. This is how the chain of responsibility pattern works. In the following video, we will examine the command pattern, so I'll see you in the next video my friends.


About the Author
Learning Paths

OAK Academy is made up of tech experts who have been in the sector for years and years and are deeply rooted in the tech world. They specialize in critical areas like cybersecurity, coding, IT, game development, app monetization, and mobile development.