Correct Use of the Mediator pattern
Hello everyone. I am designing a small application and I am thinking of using the mediator pattern. But I'm not sure how exactly this mediator should be used.
Should a frame construct a 'GUI mediator' which will then coordinate its components...
publicclass MyFrameextends JFrame{
public MyFrame(){
JButton button_1 =new JButton();
JButton button_2 =new JButton();
GUIMediator mediator = GUIMediator.getInstance();
mediator.registerButtom_1(button_1);
mediator.registerButtom_2(button_2);
}
}
Or should the frame be constructed by the GUIMediator...
publicclass GUIMediator{
public JButton button_1 =new MyButton(this);
public JButton button_2 =new MyButton(this);
public JFrame frame =new MyFrame(this);
// Mediator methods?/font>
}
publicclass MyFrameextends JFrame{
GUIMediator mediator;
public MyFrame(GUIMediator mediator){
this.mediator = mediator;
add(mediator.button_1);
add(mediator.button_1);
}
// MyFrame methods?/font>
}
publicclass MyButtonextends JButton{
GUIMediator mediator;
public MyButton(GUIMediator mediator){
this.mediator = mediator;
}
// MyButton methods?/font>
}
Or should the mediator construct a frame which inturn constructs the indiviual components...
publicclass GUIMediator{
public JButton button_1;
public JButton button_2;
public JFrame frame =new MyFrame(this);
// Mediator methods?/font>
publicvoid registerButtom_1(MyButton button_1){
this.button_1 = button_1;
}
publicvoid registerButtom_2(MyButton button_2){
this.button_2 = button_2;
}
}
publicclass MyFrameextends JFrame{
public MyFrame(){
JButton button_1 =new JButton();
JButton button_2 =new JButton();
GUIMediator mediator = GUIMediator.getInstance();
mediator.registerButtom_1(button_1);
mediator.registerButtom_2(button_2);
}
}
The above code samples show three [slighty] different ways to use a GUI mediator. Which is the preferred way/common way to implement its use? Any advice?
Best regards.
[4379 byte] By [
marek.ja] at [2007-10-2 7:22:50]
匒ny suggestions or advice will be much appreciated.Thank you.
I can't speak about preferred way/common way, I'll just expose my personal "taste"
1) I never subclass Swing components. I deem subclassing a component should be done only when defining a library of reusable widgets, which I never happened to do.
Instead I use a composer class to create standard Swing widgets, organize them into container, and wire them together using listeners and a Mediator.
I am relatively tolerant about subclassing JFrame, as I acknowledge it is convenient, but the subtyping makes no sense IMHO, where composition is the real logical relation (your application is not a JFrame, it is an accounting/inventory/whatever application that happens to have a GUI displayed in a JFrame).
Generally my Composer class and the Mediator coalesce, as it would be redundant to have both classes have knowledge of all widgets.
So it's more along the lines of your second proposition.
2) The full-fledged Mediator as presented in the GoF book involves an AbstratMediator interface which can be implemented in various ways (ConcreteMediator(s)). This means the same set of widgets could be orchestrated in various ways, and merely goes towards keeping the composer and mediator implementation in seperate classes.
I have never met this need in my apps, and most Mediator examples I've seen on the Web though seem to not use it either, and have only one Mediator implementation.
3) When designing GUIs the MVC way, I sometimes have trouble identifying what responsibilites belong to a View-level Mediator, and which ones belong to the Controller.
I usually end up with a class that does both, which coupled with my point 1) may end up in a quite big class.
I think this point needs to be more cleanly handled for complex GUIs (I haven't worked on ones big enough or variable enough to find this a maintenance problem, but I still find it uncomfortable).
4) I assume your JFrame is just an example, but to make things explicit: I make one Mediator per independant "pane". Generally the pane is a window (JFrame), but if a given window is split in 3 areas of related widgets, it's easier to maintain 3 simple Mediators instead of 1 big one.
There can be one simple mediator on top to mediate between the 3 simple ones.
Thanks for your response.
My confusion comes from the fact that a 憁ediator?should coordinate the interactions between GUI components, and may not necessarily create these components. Researching didn抰 help either ?as each coded example I looked at implemented the pattern in a different way.
Your reply helped tremendously though, but now I have another question regarding this 憁ediator?pattern?br>
Consider the following [inheritance based] code:-
public class MyButton {
private Mediator m;
public MyButton(Mediator m) {
this.m = m;
}
}
Why is it nessecary to pass in a reference of the 憁ediator?if it抯 a singleton? Why not obtain a handle to the 憁ediator?as follows:-
public class MyButton {
private Mediator mediator = Mediador.getInstance();
public MyButton() {
//myButton methods
}
}
All view points on this and my original post (above) are welcome.
I'm sorry you didn't get more comments, and I'm interested too in how other people use Mediator.
Note I have one more argument in favor of letting the Mediator build the mediated :
> [new question] Why is it nessecary to pass in a reference of the
> 憁ediator?if it抯 a singleton?
I don't find it a good idea to make the mediator a singleton:
If at some point your application displays 2 windows of the same type (say, "Customer Details"), each one will need its own Mediator instance.
Plus, you will make it difficult to reuse the graphical subclasses (although I don't like them much) : they do require the Mediator class, and notify the Mediator instance. Having the Mediator argument in their constructor makes it explicit. Hiding usage of the Mediator is misleading.
Sorry, edition error, I skipped proof-reading before posting:> Note I have one more argument in favor of letting the> Mediator build the mediated : Forget this line: nothing to do with the discussion on the singleton Mediator...
Thanks for your reply jduprez. You made a valid point concerning the Mediator building the mediated.
Back to your first reply, however, where you state that each component should be constructed through composition as opposed to using inheritance. I have some questions regarding this:
On what circumstances do you choose inheritance over composition? For example, when creating a complex GUI that is made up of many components it is common to use composition. However, what if I'm developing a custom component, would I use composition? For example, what if I was to create a 憇pecialized?Label. The following [simplified] example uses composition to define this 'specialized' Label:-
public class TimeLabel {
private final JLabel LABEL = new JLabel();
public TimeLabel() {
...
}
public void setTime(Time theTime) {
LABEL.setText(theTime.toString());
}
}
The above class posses a problem - How would the label be added to a container? Would I have to provide a getLabelComponent method, as below:
public JLabel getLabelComponent() {
return LABEL;
}
or perhaps a factory method returning the LABEL at construction time?
public class TimeLabel {
private final JLabel LABEL = new JLabel();
private TimeLabel() { ... }
public JLabel getTimeLabel() {
new TimeLabel();
return LABEL;
}
...
}
Or would it be better for the TimeLabel class to extend JLabel? What if I wanted to create a custom button, would I extend JButton or use composition?
Again, any advice is much appreciated.
