Java Reference
In-Depth Information
Chapter 10. Mediator
Ordinary object-oriented development distributes responsibility as far as it will go, with each
object doing its own work independently. The O
BSERVER
pattern supports this distribution by
minimizing the responsibility of an object that other objects find interesting. The S
INGLETON
pattern resists the distribution of responsibility to let you centralize respon-sibility in
particular objects that clients locate and reuse. The M
EDIATOR
pattern too centralizes
responsibility but for a particular set of objects rather than for all the clients in a system.
Providing a central authority for a group of objects is useful when the interactions the objects
gravitate toward the complex condition in which every object is aware of every other object in
the group. Centralization of responsibility is also useful when the logic surrounding
the interactions of the related objects is independent of the other behavior of the objects.
The M
EDIATOR
pattern defines an object that encapsulates how a set of objects interact. This
promotes loose coupling, keeping the objects from referring to one another explicitly, and lets
you vary their interaction independently.
A Classic Example: GUI Mediators
You will probably most often encounter the M
EDIATOR
pattern when you develop
an application with a GUI. Such applications tend to become
thick,
gathering code that you
can refactor into other classes. The
FlightPanel
class in Chapter 4, Facade, initially
performed three roles.
Before you refactored it, this class acted as a display panel, as a complete GUI application,
and as a flight path calculator. After refactoring, the application that launches the flight panel
display became simple, containing just a few lines of code. Large applications, however, can
remain complex after this type of refactoring, even when they contain just the logic that
creates components and that arranges for the components' interaction.
Consider the application in Figure 10.1. Oozinoz stores chemical batches in rubber tubs
supplied by the Dubdub Rubber Tub company. Machines at Oozinoz read bar codes on
the tubs to keep track of where tubs are in the factory. Sometimes, though, a manual override
is necessary, particularly when humans move a tub instead of waiting for a robot to transfer it.
In this case, the application in Figure 10.1 lets a user specify the machine at which a tub is
located. The user types in the tub ID, chooses a machine from a list, and clicks Ok! to make
the association. Figure 10.2 shows the application class.
