The mediator pattern, Conflict, Mediation and negotiation

[ Pobierz całość w formacie PDF ]
33
T
HE
M
EDIATOR
P
ATTERN
When a program is made up of a number of classes, the logic and
computation is divided logically among these classes. However, as more of
these isolated classes are developed in a program, the problem of
communication between these classes become more complex. The more each
class needs to know about the methods of another class, the more tangled the
class structure can become. This makes the program harder to read and harder
to maintain. Further, it can become difficult to change the program, since any
change may affect code in several other classes. The Mediator pattern
addresses this problem by promoting looser coupling between these classes.
Mediators accomplish this by being the only class that has detailed
knowledge of the methods of other classes. Classes send inform the mediator
when changes occur and the Mediator passes them on to any other classes
that need to be informed.
An Example System
Let’s consider a program which has several buttons, two list boxes
and a text entry field:
When the program starts, the Copy and Clear buttons are disabled.
34
1.
When you select one of the names in the left-hand list box, it is copied
into the text field for editing, and the
Copy
button is enabled.
2.
When you click on
Copy,
that text is added to the right hand list box, and
the
Clear
button is enabled.
3.
If you click on the
Clear
button, the right hand list box and the text field
are cleared, the list box is deselected and the two buttons are again
disabled.
User interfaces such as this one are commonly used to select lists of
people or products from longer lists. Further, they are usually even more
complicated than this one, involving insert, delete and undo operations as
well.
Interactions between Controls
The interactions between the visual controls are pretty complex, even
in this simple example. Each visual object needs to know about two or more
others, leading to quite a tangled relationship diagram as shown below.
35
name text
Copy
Clear
Kid list
Picked list
The Mediator pattern simplifies this system by being the only class
that is aware of the other classes in the system. Each of the controls that the
Mediator communicates with is called a Colleague. Each Colleague informs
the Mediator when it has received a user event, and the Mediator decides
which other classes should be informed of this event. This simpler interaction
scheme is illustrated below:
name text
Copy
Clear
Mediator
Kid list
Picked list
The advantage of the Mediator is clear-- it is the only class that
knows of the other classes, and thus the only one that would need to be
changed if one of the other classes changes or if other interface control
classes are added.
36
Sample Code
Let’s consider this program in detail and decide how each control is
constructed. The main difference in writing a program using a Mediator class
is that each class needs to be aware of the existence of the Mediator. You start
by creating an instance of the Mediator and then pass the instance of the
Mediator to each class in its constructor.
Mediator med = new Mediator();
kidList = new KidList( med);
tx = new KTextField(med);
Move = new MoveButton(this, med);
Clear = new ClearButton(this, med);
med.init();
Since, we have created new classes for each control, each derived
from base classes, we can handle the mediator operations within each class.
Our two buttons use the Command pattern and register themselves
with the Mediator during their initialization. Here is the Copy button:
public class CopyButton extends JButton
implements Command
{
Mediator med; //copy of the Mediator
public CopyButton(ActionListener fr, Mediator md)
{
super("Copy"); //create the button
addActionListener(fr); //add its listener
med = md; //copy in Mediator instance
med.registerMove(this); //register with the Mediator
}
public void Execute()
{ //execute the copy
med.Copy();
}
}
The Clear button is exactly analogous.
The Kid name list is based on the one we used in the last two
examples, but expanded so that the data loading of the list and registering the
list with the Mediator both take place in the constructor. In addition, we make
the enclosing class the ListSelectionListener and pass the click on any list
item on to the Mediator directly from this class.
public class KidList extends JawtList
implements ListSelectionListener
{
37
KidData kdata;
//reads the data from the file
Mediator med;
//copy of the mediator
public KidList(Mediator md)
{
super(20); //create the JList
kdata = new KidData ("50free.txt");
fillKidList(); //fill the list with names
med = md; //save the mediator
med.registerKidList(this);
addListSelectionListener(this);
}
//----------------------------------
public void valueChanged(ListSelectionEvent ls)
{
//if an item was selected pass on to mediator
JList obj = (JList)ls.getSource();
if (obj.getSelectedIndex() >= 0)
med.select();
}
//----------------------------------
private void fillKidList()
{
Enumeration ekid = kdata.elements();
while (ekid.hasMoreElements()) {
Kid k =(Kid)ekid.nextElement();
add(k.getFrname()+" "+k.getLname());
}
}
}
The general point of all these classes is that each knows about the
Mediator and tells the Mediator of its existence so the Mediator can send
commands to it when appropriate.
The Mediator itself is very simple. It supports the Copy, Clear and
Select methods, and has register methods for each of the controls:
public class Mediator
The text field is even simpler, since all it does is register itself with
the mediator.
public class KTextField extends JTextField
{
Mediator med;
public KTextField(Mediator md) {
super(10);
med = md;
med.registerText(this);
}
}
[ Pobierz całość w formacie PDF ]

The mediator pattern, Conflict, Mediation and negotiation

Linki