- 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
Mediator Base Class
The mediator base class, which is illustrated in Listing 2, is called ConnectionDirector. Notice that I use the term Connection rather than LSP because Connection is more generic than LSP. The intention is to keep the base class as clean (that is, generic) as possible.
Listing 2 Mediator Base Class: ConnectionDirector
class ConnectionDirector { public: explicit ConnectionDirector(void); virtual ~ConnectionDirector(void); virtual void WidgetChanged(Widget*) = 0; protected: ConnectionDirector(int); virtual void CreateWidgets() = 0; };
Two things are notable about ConnectionDirector:
- The virtual function WidgetChanged(Widget*)
- The CreateWidgets() protected method
Remember that mediators are used to manage multielement entities, such as complex dialog windows. In Listing 2, the method WidgetChanged() is used to tell the mediator that a widget (or subelement) has changed. The rather clever (well, I think it’s clever!) thing is that the widgets tell the mediator that they’ve changed. This avoids overworking the mediator in that the dependent objects inform it of changes rather than requiring the mediator to ask for change details.
The CreateWidgets() method is used to create the subelements. Don’t worry about the details at this point. It will all become clear as we progress through the code!