Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides
"Define an object that encapsulates how a set of objects interact. Mediator promotes loose coupling by keeping objects from referring to each other explicitly, and it lets you vary their interaction independently." (Gamma, E., R. Helm, R. Johnson, and J. Vlissides. Design Patterns: Elements of Reusable Object-Oriented Software. Reading, MA: Addison-Wesley, 1995)
Object-oriented design encourages the distribution of behavior among objects. Such distribution can result in an object structure with many connections between objects; in the worst case, every object ends up knowing about every other. Consider the implementation of dialog boxes in a graphical user interface. A dialog box uses a window to present a collection of widgets such as buttons, menus, and entry fields. Often there are dependencies between the widgets in the dialog. For example, a button gets disabled when a certain entry field is empty. Selecting an entry in a list box (Colleague in the thumbnail) might change the contents of an entry field (Colleague in the thumbnail). Conversely, typing text into the entry field might automatically select one or more corresponding entries in the list box. Once text appears in the entry field, other buttons may become enabled that let the user do something with the text, such as changing or deleting the thing to which it refers. Different dialog boxes will have different dependencies between widgets. Collective behavior may be encapsulated in a separate mediator object. A mediator is responsible for controlling and coordinating the interactions of a group of objects. The mediator serves as an intermediary that keeps objects in the group from referring to each other explicitly. The objects only know the mediator. For example, FontDialogDirector (ConcreteMediator in the thumbnail) can be the mediator between the widgets in the dialog box. A FontDialogDirector object knows the widgets in a dialog and coordinates their interaction. The director mediates between the list box and the entry field. Widgets communicate with each other only indirectly, through the director. The events by which list boxs selection passes to an entry field: the list box tells its director that it has changed; the director gets the selection from the list box; the director passes the selection to the entry field; now that the entry field contains some text, the director enables button(s) for initiating an action (e.g., "demibold," "oblique"). The FontDialogDirector abstraction can be integrated into a class library by creating the DialogDirector (Mediator in the thumbnail) as an abstract class that defines the overall behavior of all dialog. Clients call the ShowDialog operation (in DialogDirector) to display the dialog on the screen. CreateWidgets (in DialogDirector) is an abstract operation for creating the widgets of a dialog. WidgetChanged (in DialogDirector) is another abstract operation; widgets call it to inform their director that they have changed. DialogDirector subclasses override CreateWidgets to create the proper widgets, and they override WidgetChanged (in FontDialogDirector) to handle the changes.
This pattern has been used on the following systems: ET++ uses director-like objects in dialogs as mediators between widgets. (Weinand, A., E. Gamma, and R. Marty, ET++--An object-oriented application framework in C++. In Object-Oriented Programming Systems, Languages, and Applications Conference Proceedings, pp. 46-57, San Diego, CA, September 1988. ACM Press. Think C class library uses director-like objects in dialogs as mediators between widgets. (Symantec Corporation, Cupertino, CA. THINK Class Library Guide, 1993.) Smalltalk/V for Windows is based on the Mediator structure. In this environment, an application consists of a Window containing a set of panes. An application developer only subclasses from ViewManager, the Mediator, a class that is responsible for doing inter-pane coordination. The panes do not refer to each other directly. (LaLonde, W., Discovering Smalltalk. Benjamin/Cummings, Redwood City, CA, 1994.)
Façade and Observer patterns
Facade pattern, Mediator pattern, Observer pattern, behavioral patterns, Gamma patterns, object composition, encapsulation (object communication), communication (centralized), object communication
any system with potential high inter-connectivity between objects
need to reduce the coupling of objects
increases reuse of classes by de-coupling the interface from the implementationprovides weak coupling between clients and subsystemsreduces subclassing
the mediator may become monolithic because of so much control
Simple implementation of the pattern - Mediator class. Mediator.javaSimple implementation of the pattern - ConcreteMediator class. ConcreteMediator.javaSimple implementation of the pattern - ConcreteColleague2 class. ConcreteColleague2.javaSimple implementation of the pattern - ConcreteColleague1 class. ConcreteColleague1.javaSimple implementation of the pattern - Colleague class. Colleague.javaTest driver testmediator.cppSimple implementation of the pattern. mediator.h