Skip to content

Behavioral Design Pattern: Chain of Responsibility Pattern

Chain of Responsibility Pattern will be our first Behavioral Design Pattern. Behavioral Design Patterns solves communication problem between different modules. They increase the flexibility in the communication process between Objects. Chain of responsibility pattern is a pretty simple pattern. It requires creation of a chain of processing objects that can process any provided task. Whenever a task needs to be done code does not relay on writing complex if..else… ladder to pass which processor needs to process which task. Task will be passed to a pipeline where each process resides and reads the inputted task one by one. Each processor has a fixed responsibility and as soon as the processor encounters any task that it can handle it will handle it otherwise it will pass the task to the next handler or processor.


When there many things that must be done depending on different type of request. We usually write complex if…else ladder to tell which processor or handler will handle the following request. This makes the code a lot more rigid and reduces it’s flexibility. Because when a change is required we need to change that complex if..else ladder of switch statement. There might be unknown problems while changing the if else statement.


What we are trying to do is to make sure we remove this if..else ladder or switch statement completely. We will follow below rules:

  1. Do not write if..else ladder or switch statements.
  2. Pass the request to first handler or processor. Processor can process the request or pass it to the next processor.
  3. Each processor must know which kind of request they will process.
  4. Each processor will be responsible for one and only one task.


First we will take a look at a generic example. First take a look at the below class diagram.

Chain of Responsibility Pattern UML diagram
Chain of Responsibility Pattern UML diagram

We have class AbsHandler. This class acts as the base class for all the handler. AbsHandler defines method setNext method to set the next item on the chain. And doTheWork method will be responsible to handle the actual work. Here is some code.

Child classes of our Base class AbsHandler can act as chain links in our chain of responsibility pattern. For our example we define four such classes. All of these four classes will define their own doTheWork method thus defining their own process to handle the request. Lets see their source.

We have completed the core part of our Chain of responsibility pattern. The only thing left is writing client code that will construct the chain using above four classes. Then our client code will try to execute the some requests via the chain created.

We can clearly see that tryHandlers method does not check for handlers by using if..else ladder or switch statements. tryHandler method just calls the first handler and rest of the handlers will be called one by one upon their turn. There are a few more benefits in the chain of responsibility pattern. Such as we can create a priority order of the handlers while constructing the chain. Chain can be constructed of threads that is each handler can be a thread which can provide pipeline process.

Lets see one more practical example of Chains of responsibility pattern.

Practical Example

In this example we will try to mock a logger class. This class will be responsible to log different message at different log level. We will create a chain of loggers and each logger will check should they print the log message. The example and it’s code is self explanatory.

This logger will work as any other logger would behave but the code is pretty clean. This is the power of chain of responsibility pattern. Well this concludes our discussion over chain of responsibility pattern.

I hope this post was of some help in understanding chain of responsibility pattern.

As always thanks for reading and comments are always welcome.


Published inDesign Patterns

Be First to Comment

    Leave a Reply

    Your email address will not be published. Required fields are marked *