The Chain of Responsibility is intended to promote loose coupling between the sender of a request and its receiver by giving more than one object an opportunity to handle the request. The receiving objects are chained and pass the request along the chain until one of the objects handles it.

image

What I like about this pattern is the chaining part. If the first handler cannot handle the request, the second one will. Or the third, fourth, or … And you only have to call the first handler of the chain.

You must be aware that if you want to use this pattern you should be very keen on exception handling, because the major drawback of this pattern is the possibility that the chain breaks.

And you probably heard this before:

A chain is only as strong as its weakest link

This also holds true for the chain of responsibility pattern. If one handler doesn’t do its work right the working of the following handlers are possibly compromised, which is especially important if the handler is one of the first components in the chain.

The client creates the chain by linking the handlers and does its request to the first handler in the chain, that’s it.


As is the case in most design patterns, there is an abstract class. The abstract class Handler defines SetSuccessor, which is responsible for the actual chaining.


The concrete class implements the actual handling of the request.

I also have included a real world example, a message handler which can handle different versions of requests. The first link in the chain handles version 1, the second version 2, and so forth…

Click here for a simplified

This post is part of my series on the foundational design patterns in C#. In this series we explore the ancient design patterns and their use in real-world programming situations of today. In these series of posts we explore each pattern and look at simplified real-world C# code that implements the pattern.