Java Reference
In-Depth Information
CHALLENGE 10.1
Complete the diagram in Figure 10.3 to show a refactoring of PlaceATub_1 ,
introducing a new PlaceATubMediator class to receive the events of
the PlaceATub GUI.
Figure 10.3. Separate the component-building and event-handling parts of the
application.
The refactoring consolidates the mediator into a separate class, letting you develop it and
focus on it separately. Now when the PlaceATub application runs, components pass events
to a PlaceATubMediator object. This object may call back components in the GUI: for
example, to select all the text in the text field when the user tabs into it. The mediator may
also call domain objects: for example, calling a Tub object's setMachine() method when
the user clicks the Ok! button.
CHALLENGE 10.2
Draw a diagram that shows what happens when the user clicks the Ok! button. Show
the button, the mediator, the affected tub, and the sequence of messages that pass
among these objects.
Java Swing components apply the M EDIATOR pattern as a matter of course, notifying a
mediator when events occur rather than taking responsibility for updating other components
directly. Swing applications give rise to perhaps the most common application of
the M EDIATOR pattern, but you may want to introduce a mediator in other cases as well.
Whenever the interaction of a set of objects is complex, you can centralize the responsibility
for this interaction in a mediator object that stands outside the interacting group. This
promotes loose coupling —a reduction in the responsibility that the interacting objects bear to
one another. Managing the interaction of objects in an independent class also has
the advantage of simplifying and standardizing the interaction rules. One example of the value
of a mediator occurs when you need to manage relational integrity.
Search WWH ::




Custom Search