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 avoids heavy-duty monolithic servers that process all event messages and call remote objects. Instead, the remote objects themselves (such as LSPs) 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 need to explicitly define 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 putting them in a central location
- Chain of responsibility may lose messages if no handler is found, so it's important to have a default event handler
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, please see [2].
In keeping with the magic of design patterns, the main point I'd like you to take away is that the chain of responsibility provides a lot of power with very little code—in this case just two source code files: EventHandler.cpp and EventHandler.h!
Get the source code for this article.
Additional Reading
[1] "Network Management, MIBs & MPLS: Principles, Design & Implementation" by Stephen Morris - includes strategies for IT folks to avoid being offshored
[2] "Design Patterns: Elements of Reusable Object-Oriented Software" by Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides, 1995, Addison-Wesley
