Java Reference
In-Depth Information
Mediator
Pattern Properties
Type: Behavioral
Level: Component
Purpose
To simplify communication among objects in a system by introducing a single object that manages message
distribution among the others.
Introduction
A useful feature in the PIM would be sharing information among several users, so that one user could set up a
meeting that other PIM users would attend. With a shared set of data, all the participants would be up-to-date on
the meeting plans.
How should you manage the appointments, assuming multiple PIMs are running? One way is to give each PIM a
copy of the
Appointment
object, ensuring that they have local access to the data. This presents a problem: how
do you ensure that information is consistent among all users? For example, if the user creates a meeting and later
changes the date, how do the other meeting participants find out?
You can make the user's application responsible for managing the update. However, if any of the meeting participants are allowed to
make updates, that means that each PIM has to keep track of all of the other PIMs. Managing communication for a large number of
participants becomes very difficult. In the best case, it is inefficient and costly in terms of network bandwidth; in the worst case, the
planning for a meeting degenerates into chaos. And generally, you'd prefer to leave the chaos to the meetings themselves.
Given the potential complexity of the system, it's better to delegate the task of sending and receiving specific requests to a central object,
which then makes decisions about what methods to call. This is the essence of the Mediator pattern. Instead of making the
Appointment
itself responsible for sending updates, create an
AppointmentMediator
. Each time
Appointment
changes, call a method in the
Mediator
object, which might decide to call methods on the Location object to
confirm. Depending on the result, the
AppointmentManager
broadcasts the original message, a revised version of
the message such as a meeting time change, or a cancellation.
Applicability
Use Mediator when:
There are complex rules for communication among objects in a system (often as a result of the business model).
You want to keep the objects simple and manageable.
You want the classes for these objects to be redeployable, not dependent on the business model of the system.
Description
As communication among objects in an application becomes more complex, managing communication becomes
more and more difficult. Handling event processing for a simple spreadsheet control might involve writing code
for the grid component. However, if the GUI is expanded to include a grid, graph, and record-display fields, it
becomes much more difficult to manage the code. A change in one of the components might trigger changes in
some or all of the others.
The Mediator pattern helps solve this problem, since it defines a class that has overall communications
responsibility. This greatly simplifies the other classes in the system, since they no longer need to manage
communication themselves, and that can help you keep much of your hair and your sanity. The mediator
object—the central object to manage communication—has the role of a router for the system, centralizing the
logic to send and receive messages. Components send messages to the mediator rather than to other components
of the system; likewise, they rely on the mediator to send change notifications to them.
Consider implementing Mediator whenever a set of GUI components should behave as a whole. The main factor
in deciding whether to implement the pattern is the overall complexity of the GUI model. Two other possible
scenarios for Mediator implementation are:
