By Steven Black
A Mediator object is a form of Observer that abstracts inter-workings of two or more objects. They are communication hubs that serve to decouple objects — objects don’t need to know about each other, they just need to know their Mediator. Mediator promotes loose coupling by keeping objects from referencing to each other explicitly, and lets you vary their interaction independently.
Look for Mediator patterns where objects are decoupled and in situations when inter-object behavior variation is present or expected. Mediators well serve situations where complex protocols must be managed, and when centralized access points are desirable.
Mediator is a behavioral pattern. When we speak of Mediator, it’s a system of at least three objects messaging in a star topology.
Figure 1. The Mediator provides a common connection point, centralized (and subclassable) behavior and behavior management, all with a common interface. As the number of colleagues increases, the number of total communication pathways is vastly reduced.
The horizontal splitter control in Tazmanian Traders, which comes from the tsGen class library in the VFP samples, contains two shapes and two scrolling command buttons. As the handle shape is moved, or the scroll buttons are clicked, messages are sent to the splitter, which then messages selected items on the form.
In Codebook, toolbar navigation buttons call a business object class (cBizObj) which mediates in a one-way direction between the form (of class cBizObjForm) and the data behavior object (of class cDataBehavior). This simplifies the programming interface — only the cBizObj class protocols need be known — and allows for the easy substitution of the data behavior implementations from the cDatabehavior class. Note that several bridge patterns are evident here separating programming interfaces from implementations.
Figure 2. Hitting the Next button in Codebook. The cBizObj class mediates between the form and the desired behavior.