Chain of Responsibility
- Avoid coupling the sender of a request to its receiver by giving more than
one object a chance to handle the request.
- Chain the receiving objects and pass the request along the chain until
an object handles it

- Handler : defines an interface for handling requests. (optional)
implements the successor link.
- ConcreteHandler : handles requests it is responsible for. can
access its successor. if the ConcreteHandler can handle the request, it does
so; otherwise it forwards the request to its successor.
- Client : initiates the request to a ConcreteHandler object on the
chain.
- more than one object may handle a request, and the handler isn't known a
priori. The handler should be ascertained automatically.
- you want to issue a request to one of several objects without specifying
the receiver explicitly.
- the set of objects that can handle a request should be specified
dynamically.
- Reduced coupling. The pattern frees an object from knowing which
other object handles a request. An object only has to know that a request
will be handled "appropriately." Both the receiver and the sender have no
explicit knowledge of each other, and an object in the chain doesn't have to
know about the chain's structure.
- Added flexibility in assigning responsibilities to objects. Chain
of Responsibility gives you added flexibility in distributing
responsibilities among objects. You can add or change responsibilities for
handling a request by adding to or otherwise changing the chain at run-time.
You can combine this with subclassing to specialize handlers statically.
- Receipt isn't guaranteed. Since a request has no explicit receiver,
there's no guarantee it'll be handled—the request can fall off the end of
the chain without ever being handled. A request can also go unhandled when
the chain is not configured properly.