Java Reference
In-Depth Information
The Mediator is often application specific and difficult to redeploy. This is hardly surprising, since the Mediator
is created to encapsulate application-specific behavior so the other classes in the system remain generic.
Centralizing application-specific behavior in the Mediator improves maintainability. You can reuse all other
classes for other applications; you only need to rewrite the Mediator class for the new application.
Testing and debugging complex Mediator implementations can be challenging, since you must accurately test a
component that consists of the Mediator and its associated objects.
The Mediator's code can become hard to manage as the number and complexity of participants increases. A
possible solution is to make the mediator a composite structure, based on a number of highly focused individual
mediators. (For more information about the composite pattern, see “ Composite ” on page 157.) In this case, the
Mediator consists of a central managing object associated with a number of individual service classes, each
providing a specific piece of functionality.
Pattern Variants
The Mediator pattern has a number of behavioral variations:
Unidirectional communication - Some implementations allow send-only and receive-only clients for the system.
Threading - Like many behavioral patterns, the Mediator is a candidate for multithreading. If multithreaded, the
Mediator object can maintain a message queue, and perform tasks like managing communications with message
priority.
Configurable roles - In this variant, clients define a role (which could possibly be changed as the system runs)
that would define messaging requirements. Although complex to implement, defining participants in terms of
roles can lead to a more generic Mediator, and one that can be redeployed to other systems.
Client pull - A Mediator can store detailed messages and send only a general notification to clients. Clients can
then request detailed information about an event if required.
Related Patterns
Related patterns include the following:
Observer (page 94) - This pattern is often used to manage communication between the Client and Mediator
when the communication is local. There is frequently only one Mediator per system, so they are sometimes coded
as Singletons or as class-level resources by making their methods static.
HOPP (page 189) - Mediator patterns that run across a network can use the Half-Object Plus Protocol (HOPP)
pattern to provide communication support.
Example
Note:
For a full working example of this code example, with additional supporting classes and/or a RunPattern class,
see “ Mediator ” on page 395 of the “ Full Code Examples ” appendix.
In this example, a Mediator manages communication among the panels of a graphical user interface. The basic
design of this GUI uses one panel to select a Contact from a list, another panel to allow editing, and a third panel
to show the current state of the Contact. The Mediator interacts with each panel, calling the appropriate methods
to keep each part of the GUI up to date.
The class MediatorGui creates the main window and the three panels for the application. It also creates a
mediator and matches it with the three child panels.
Example 2.25 MediatorGui.java
1. import java.awt.Container;
2. import java.awt.event.WindowEvent;
3. import java.awt.event.WindowAdapter;
4. import javax.swing.BoxLayout;
Search WWH ::




Custom Search