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 a set of logic that describes the types of command objects that it can handle, and how to pass off those that it cannot 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 (parsed, but not yet executed) might be a fitting example.
This pattern promotes the idea of loose coupling, which is considered a programming best practice.
Applicability
We use the Chain of Responsibility when
· You have more than one handler that can handle a request and
there is no way to know which handler to use. The handler must
be determined automatically by the chain.
· You want to issue a request to one of several objects without
specifying which one explicitly.
· You want to be able to modify the set of objects dynamically that
can handle requests.
A Chain or a Tree?
Of course, a Chain of Responsibility does not have to be linear. It is more
generally a tree structure with a number of specific entry points all pointing
upward to the most general node.
However, this sort of structure seems to imply that each button, or is
handler, knows where to enter the chain.
Consequences of the Chain of Responsibility
1. The main purpose for this pattern, like a number of others, is to reduce
coupling between objects. An object only needs to know how to forward
the request to other objects.
2. This approach also gives you added flexibility in distributing
responsibilities between objects. Any object can satisfy some or all of the
requests, and you can change both the chain and the responsibilities at run
time.
3. An advantage is that there may not be any object that can handle the
request, however, the last object in the chain may simply discard any
requests it can’t handle.
4. Finally, since Java can not provide multiple inheritance, the basic Chain
class needs to be an interface rather than an abstract class, so that the
individual objects can inherit from another useful hierarchy. This disadvantage
of this approach is that you often have to implement the linking, sending and
forwarding code in each module separately.
Kinds of Requests
The request or message passed along the Chain of Responsibility may
well be a great deal more complicated than just the string that we
conveniently used on this example. The information could include various
data types or a complete object with a number of methods. Since various
classes along the chain may use different properties of such a request object,
you might end up designing an abstract Request type and any number of
derived classes with additional methods.
Examples in Java
The most obvious example of the Chain of Responsibility is the class
inheritance structure itself. If you call for a method to be executed in a deeply
derived class, that method is passed up the inheritance chain until the first
parent class containing that method is found.