Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Conclusion
The chain of responsibility pattern provides an interesting technique for equipping related objects with more intelligence. This allows for a concomitant reduction in the intelligence of a central event handler. This facilitates avoiding heavy-duty servers that process all messages and call remote objects. Instead, the remote objects can provide their own handlers for messages. The overhead for doing this is pretty light—a successor variable is required along with an event holder. In addition to this, we would need a message dispatcher to get the chain going.
Some of the tradeoffs for the chain of responsibility pattern include the following:
- The need to explicitly define all event types in the objects risks cluttering our class definitions. However, events have to be defined anyway, even if we use a central event handler. Placing event definitions in the classes is often more meaningful than a central location.
- The chain of responsibility might lose messages if no handler is found.
An advantage is that objects are equipped with event handlers for only those events that matter to them. This allows for a more real world lightly coupled object model. (To find out more about the chain of responsibility pattern, see the second reference in the Additional Reading section.)
The main point to take away is that chain of responsibility provides a lot of power with very little code—in this case consisting of two source code files: EventHandler.cpp and EventHandler.h!