The Chain of Responsibility pattern establishes a chain within a system, so that a message can either be handled at the level where it is first received, or be directed to an object that can handle it.
The following lists the benefits of using the Chain of Responsibility pattern:
- Reduced coupling
- Added flexibility in assigning responsibilites to objects
- Allows a set of classes to behave as a whole, because events produced in one class can be sent on to other handler classes within the composite.
You should use the Chain of Responsibility Pattern when:
- More than one object can handle a request, and the handler is not known.
- You want to issue a request to one of several objects without specifying the receiver completely.
- The set of objects that can handle a request should be specified dynamically.
In Object Oriented Design, the chain-of-responsibility pattern is a design pattern consisting of a source of command objects and a series of processing objects.
Each processing object contains logic that defines the types of command objects that it can handle; the rest are passed to the next processing object in the chain.
A mechanism also exists for adding new processing objects to the end of this chain.
In a variation of the standard chain-of-responsibility model, some handlers may act as dispatchers, capable of sending commands out in a variety of directions,
forming a tree of responsibility. In some cases, this can occur recursively, with processing objects calling higher-up processing objects with commands that attempt
to solve some smaller part of the problem; in this case recursion continues until the command is processed, or the entire tree has been explored. An XML interpreter might work in this manner.
This pattern promotes the idea of loose coupling, which is considered a programming best practice.