Design patterns: Chain of responsibility

Today will be the theme, as I promised in the previous article, about the design pattern called a chain of obligations, also known as the chain of responsibility, it is perfect for assigning responsibilities to every employee in the company, well …🙂 we’re going with the topic 🙂



At the beginning of the introduction, some people accused me of having some too complicated terminology in my entries and wouldn’t recommend it to beginners, or more precisely to those who are just learning to program. Of course, the design patterns are not ✋ for beginners in programming, mainly because the beginners usually do everything in a way, “as only as it works”, design patterns are for people who have happen to write some dirty 😥 code and such people will already know, that doing everything in a way “as only as it works” has very short legs.

And, if someone does not know what an abstract class or interface is, let’s not take for design patterns too because these concepts are used in most of the patterns. I try to write in a simple language, but in programming and especially in design patterns, it is very difficult and to understand a given pattern sometimes you need to use this complicated terminology a little, but if I do something what somehow will be something incomprehensible even for people who already sit a little subject, of course I am open to any comments, you can contact me on the Contact page or simply write in the comments. And that would be all in the introduction. Let’s go to the pattern overview.



The chain of responsibility is used to transfer tasks in the objects chain ⛓ (hence the name of the pattern) and depending on the task received, the object that received the task checks whether it fulfills the condition for completing the task, if not, forward the request to subsequent objects. The picture below illustrates it well.

Chain of responsibility example

The client sends request and all objects in turn check whether they are authorized to perform this request and the main part of the pattern implementation consists of a linked list and an abstract class that can be said to be a template for this list.

And just to understand this pattern you need to know what a linked list is.


Linked list

A linked list is a structure in which each element knows the address of the next element.

The .NET platform is ready, implemented a one-way list, for those who write in C++, here is an example of a linked list, also in other languages the implementation may look different, well, everyone must to match the implementation of a linked list to own language. But generally a description of all examples of design patterns can be easily transferred from C# to Python, C++, Java, etc. 🙂 Design patterns and practice of writing clean code will be useful to everyone regardless of language.

The example below:

This is an example of a linked list, each element of the list knows the address of the next element, in the above example first we adding elements to the list at the beginning, then add the next element to the first element of the list and add another element to the previously added element, notice what happens happens, every element of the list knows what its next element is.


Similarly, the pattern chain of responsibility works in this way, it is known where to forward client requests, in this case to the next object in the structure.

I think I know how often you feel when you learn design patterns, probably like this sir below 🙂

Relax, it’s not so terrible despite appearances, let’s move on 🙂



  • Support sent request by the objects chain that provides the request support or forwards it.
  • Sending a request to a chain that contains many handlers (objects that can handle the request)



You can use the object chain pattern as it was in the introduction to manage tasks, or there where are wherever there are mechanisms with similar requests, imagine a situation where we must effectively handle a large number of requests without having to write classes with dependencies.

Chain of responsibility example


Use when:

  • You want to assign tasks to different objects quickly and easy.
  • For example, you want to implement a request processing engine in which it will be easy to add support new types, or if necessary, remove them.



The pattern diagram of the chain of responsibility consists of:

  • An abstract class of Handler in which the handle() method is defined, which send requests further if the request does not match a given object and a linked list whose elements are objects in the chain, each object knows what is the next object in the list.
  • Classes that inherit from the Handler class and which process requests, if the request matches, they process it if they do not forward to the next object in the queue.

Chain of responsibility scheme

Below, an example of a chain pattern. It is simple example so that you can easily understand it.

The equivalent of the Handler class from the UML diagram is the Number class. It stores the object from the chain and defines the method forwarding the request.

The classes of the chain are classes One, Two, Three.

All of these classes inherit from the Number class, thanks to which they can pass on requests further.

And launching that in the client.

In the client, we first create instances of classes belonging to the chain, and save these objects in a linked list, so that the next object to which we forward the request knows what is next, just to know to which object to forward the request. We have saved the types of requests in the enum enumeration type in the QuestsOnToday list.

Finally, we pass the requests in the foreach loop one by one.




  • When a client sends a request, the client doesn’t know which of the objects will handle it.
  • The possibility of an easy and flexible allocation of responsibilities to Handle objects (that is, objects that support customer requests).



  • The lack of a guarantee of request handle, thus also the operation of the chain is more difficult to debug.



Payments for employees

In this example, we will be checking, what payment on which position who should get, that is, if we enter in the console 4000, we check that the payout is 4000, for example for a director.

The equivalent of the Handler class from the UML diagram looks like this.

The object chain looks like this.

We see that it looks similar to the previous example with the diagram, but it differs a bit, mainly the redirecting method already has a body in the abstract class PurchasePower and is not extended by each object in the chain.

Let’s look at how it looks in the client.

It also looks similar to the previous example, but differs in that while in a while loop we enter the value, it is saved in the PurchaseRequest class object and then it is sent to the PurchasePower class to the processRequest() method.

And let’s see what the PurchaseRequest class looks like.

It can be seen that payment data is saved in this class, we can display or set it. Analyze this example exactly, always will be a link at the end of the lesson to github with all the examples.



Real-life example

Withdrawal from an ATM

We will make another example on the principle of withdrawing money 💵 from an ATM, we will be send requests that will be check what the user chose.

Chain of responsibility example

First, abstract class Pay, which is a linked list template, and defines a method that redirects requests to subsequent objects.

And of course, a chain of objects that check sent requests.

And running everything in the client.

So the procedure is similar to the one shown in the chain master scheme, we have an abstract Pay class, which is the equivalent of the Handle class from the UML diagram and we have a chain of classes that inherit from the Pay class. And we create class instances in the client and write them on the principle of a linked list, and the client chooses the option how much money he wants to pay out depending on what he chose we send the request, which each object in the chain checks in turn, starting from the PayHundred class because it is first in line.



Relations wit other design patterns

  • The chain of responsibility can use the Command pattern to represent requests as objects.
  • Mediator patterns, chain of responsibility, Command, Observer show how you can separate recipients and senders. The chain of responsibility passes the request along the chain of potential recipients.



That’s all about on subject the Chain of responsibility pattern🙂

Link to github with all examples:

This content also you can find on my steemit blog

And on medium:

If you have endured to the end, he congratulates you 👏. If you have read about other design patterns on this blog and you’ve study them and you understand all of them, then you’re not a beginner programmer anymore, but you already have a certain skill. 👍

In the next article, we will talk about the Mediator design pattern.

As a standard, I remind you about the newsletter, which I send notifications about new entries and additional information about the IT world in general.

And NECESSERILY join the DevmanCommunity community on fb, part of the community is in one place 🙂

– site on fb:ławomir Kowalski

– group on fb: DevmanCommunity

Ask, comment underneath at the end of the post, share it, rate it, whatever you want🙂.

If that post was useful for you share it with your friends :)

Post a comment

Notify about