The chain of responsibility behavioral pattern allows you to setup a series of possible results that you can initiate from a single location without worrying about what code will provide the result. Usually this pattern describes a single outcome but there can be more.
Many times, this pattern works with the composite design pattern in order to know which object to call next. The composite pattern provides a nice hierarchy of objects but you don’t have to use that pattern or that structure. As long as you have some means to provide one or more possible result handlers that each know about the next handler in line, then you have the means to follow this pattern.
Your code just calls the first handler and it can choose to do something or move to the next. These are just method calls and a handler is some object that decides it’s the best object to deal with the method call. If not, then the object passes control to the next object by calling the same method on the next object. The order that the handlers are called is very important and you normally want to make sure that the possible handlers are ordered so they’re looking at very specific criteria first, then a little broader criteria, then a little more, and so on, until you may want some handler that acts as a catch-all.
This pattern doesn’t guarantee that your request will be handled or which object will handle the request. That flexibility allows you to reduce coupling between your objects. If you know exactly which object you want to call to process a method call, then this pattern is not for you.
The decorator design pattern also calls from one object to the next. There is a big difference between these two patterns though. The decorator is trying to add new features or behavior to a base object. The chain of responsibility is just trying to figure out who will handle the request.