DOC PREVIEW
UMD CMSC 433 - Mediator Pattern

This preview shows page 1-2 out of 5 pages.

Save
View full document
View full document
Premium Document
Do you want full access? Go Premium and unlock all 5 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 5 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 5 pages.
Access to all documents
Download any document
Ad free experience

Unformatted text preview:

1CMSC 433 – Programming Language Technologies and ParadigmsSpring 2007Mediator PatternApr. 12, 20072Example• 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.• 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.3Example (cont…)• When you click on Copy, that text is added to the right hand list box, and the Clear button is enabled.• 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.4Relationship Diagram• The interactions between the visual controls are pretty complex. • Each visual object needs to know about two or more others, leading to quite a tangled relationship diagram.5Mediator• The Mediator pattern simplifies this system by being the only class that is aware of the other classes in the system. • The controls that the Mediator communicates with is 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.6Why Mediator?• 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.7The Code!• 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.8KTextField• The text field registers itself with the mediator.9The Copy Button• Our two buttons use the Command pattern and register themselves with the Mediator during their initialization.10The Kid name list…• The data loading and registering of the Kid name 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.11The Rest of the Code…12General Mediator Philosophy• 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.13The Mediator Code!• The Mediator itself is very simple. – It supports the Copy, Clear and Select methods, and has register methods for each of the controls.14More Mediator Code!15Yet More Mediator Code!16System Initialization• One further operation that is best delegated to the Mediator is the initialization of all the controls to the desired state. • When we launch the program, each control must be in a known, default state, and since these states may change as the program evolves, we simply create an init method in the Mediator, which sets them all to the desired state. • In this case, that state is the same as is achieved by the Clear button and we simply call that method.public void init() {Clear();}17Concluding Remarks• The Mediator makes loose coupling possible between objects in a program. – It also localizes the behavior that otherwise would be distributed among several objects.• You can change the behavior of the program by simply changing the Mediator.• The Mediator approach makes it possible to add new Colleagues to a system without having to change any other part of the program.• The Mediator solves the problem of each Command object needing to know too much about the objects and methods in the rest of a user interface.18More Concluding Remarks• The Mediator can become complex, making it hard to change and maintain. – Sometimes you can improve this situation by revising the responsibilities you have given the Mediator. – Each object should carry out it’s own tasks and the Mediator should only manage the interaction between objects.• Each Mediator is a custom-written class that has methods for each Colleague to call and knows what methods each Colleague has available. – This makes it difficult to reuse Mediator code in different projects. – On the other hand, most Mediators are quite simple and writing this code is far easier than managing the complex object interactions any other


View Full Document

UMD CMSC 433 - Mediator Pattern

Documents in this Course
Trace 1

Trace 1

62 pages

Reflection

Reflection

137 pages

Testing

Testing

25 pages

Paradigms

Paradigms

10 pages

Testing

Testing

17 pages

Java RMI

Java RMI

17 pages

Java RMI

Java RMI

17 pages

Java RMI

Java RMI

17 pages

Trace 1

Trace 1

46 pages

Jini

Jini

4 pages

Final

Final

15 pages

Java RMI

Java RMI

13 pages

Testing

Testing

16 pages

Load more
Download Mediator Pattern
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view Mediator Pattern and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Mediator Pattern 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?