- Object Interactions
- Object Interaction Scenario in IT Management
- Example of a Mediator
- Mediator Base Class
- Mediator Subclass
- Widget Class
- Two Widget Subclasses
- LspDirector Implementation
- Widget Class Implementation
- PathWidget Class Implementation
- Putting It All Together
- Conclusion
- Additional Reading
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Conclusion
The mediator pattern provides for object decoupling. It is often described as desirable—and with good reason! In general, objects should have high cohesion and low coupling. One important benefit is the ability to extract such objects for reuse or repackaging as services (in service-oriented architectures).
When you use the mediator pattern, try not to dump a lot of complexity in the mediator class. The latter should be as close as possible to a traffic cop: just directing the interobject calls. If your mediator is doing a lot of work processing messages, it’s possible you need to move this code out of the mediator and into a new client class.
Also, remember that the mediator object might represent a single point of failure in your code because it functions as a type of message exchange server. If your code has high availability requirements, you might need to rethink the mediator structure.
The mediator pattern is closely allied with the observer pattern in that it monitors the state of the dependent objects. In one sense, the mediator provides an implementation of the observer pattern.
The source code for this article (which can be downloaded in "Additional Reading," consists of five C++ header files and six C++ implementation files. To build this code and try it for yourself, just create a Visual C++ console project, drop the files in, switch off precompiled headers and you’re ready to rock and roll!