Mediator Pattern - A. Friedrich, C. Ho, D. Heaton - SENG 443 - University of Calgary - November 2004
Table of Contents
- Introduction
- Air Traffic Controller Example
- Participants
- Applicability
- Consequences
- Examples
- Related Patterns
- Known Uses
- Previous Experience
- Conclusion
- References
- Contact Information
Introduction
The Mediator is a behavioral design pattern that provides a central hub to guide the interactions between many objects. According to Gamma et al, the intent of the Mediator pattern is to,
"Define an object that encapsulates how a set of objects interact.
Mediator promotes loose coupling by keeping objects from referring to
each other explicitly, and it lets you vary their interaction
independently." (Gamma et al., 1995)
You will find on this page, a detailed, and hopefully useful, investigation into the various aspects of this relatively simple, yet powerful design pattern.
Air Traffic Controller Example
Before we explore the Mediator pattern in any depth, first consider the example of an air traffic controller, and the various aircraft it helps to guide (Bains K., Lau E., 2002).
Imagine what would happen if there were no air traffic controllers. Each and every aircraft would have to know about every other aircraft in order to avoid collisions with them. This would certainly be a cause for disaster, as it would be far too difficult for each plane to keep track of all other aircraft in the vicinity.
So, to remedy this, we have the air traffic controller. Instead of having all aircraft communicating directly with one another, they simply send the controller their flight data and the controller then decides what other aircraft need to be informed. This is clearly far more efficient, and in this case, much safer, than the alternative. This is a perfect example of the Mediator pattern in the real-world.
Structure
Expressed in UML, a Mediator pattern may be structured with a handful of simple classes and interfaces (Figure 1.).
So an example implementation, in the context of the air traffic controller described earlier, could also be structured in UML (Figure 2.).
The sequence of events that may occur between the objects involved in our air traffic controller example, can be expressed using a sequence diagram (Figure 3.).
More or less, this is how the Mediator design pattern works. Colleagues inform the Mediator of particular events, and the Mediator then decides what other colleagues should be informed.
Participants
There are three participants in the Mediator pattern (Figure 1.):
- Mediator: defines an interface for communicating with Colleague objects (Gamma et al., 1995).
- ConcreteMediator: is the object that coordinates the Colleague objects and is in charge of the messages they wish to send to each other. A ConcreteMediator knows and maintains its Colleagues (Gamma et al., 1995).
- Colleague classes: each Colleague class knows its Mediator object, and communicates with it whenever it would have otherwise communicated with another Colleague (Gamma et al., 1995).
Applicability
According to Gamma et al, the Mediator pattern should be used when (Gamma et al., 1995):
- a set of objects communicate in well-defined but complex ways. The resulting interdependencies are unstructured and difficult to understand.
- reusing an object is difficult because it refers to and communicates with many other objects.
- a behaviour that's distributed between several classes should be customizable without a lot of subclassing.
Consequences
As with most design patterns, there are both advantages and disadvantages to using the Mediator. The following section will briefly outline a few of these issues.
Advantages
- Comprehension: Since the Mediator hides all coordination activities that it implements, the user is better able to understand the system and the interactions that that the Colleagues make.
- Decoupled Colleagues: Colleagues can be added/removed/modified easier as they depend less on each other. This also goes between the Colleague and its Mediator- they can be used independently.
- Ease of Protocols: The Mediator makes sure that there are only a few centralized access points. The one-to-many relationship of the Mediator is much preferred to over the many-to-many relationship among Colleagues. (Black, 2004)
- Limits Subclassing: The Mediator localizes behavior. Only the Mediator needs subclassing when changing behavior; the Colleagues can remain the same.
Disadvantages
- Complexity: Because the Mediator may handle a potentially large number of Colleagues, the contents of the Mediator may be very complex. Thus, it could be difficult to modify its and understand its contents.
Examples
Parliament
The House of Commons in the Parliaments of Canada, England and many more countries are also excellent real-life examples of the mediator pattern. According to protocols established hundreds of years ago, Members of Parliament (Colleagues) may never address each other directly. All comments are instead directed to the Speaker of the House (the Mediator). Further, it is a breach of protocol to refer to a member by name. All members are referred to as "The Honourable Member from [district]" or "My good friend from [district]." This is analogous to addressing Colleague classes by their "interface" and not by their actual "implementation".
Chatroom
To illustrate a possible use of the Mediator pattern, we have chosen to
present an example chatroom application (Data & Object Factory, 2004)
in Java. In this particular example, the Forum acts as the abstract
Mediator, and the PoliticalForum is the concrete
implementation of it. We then have a couple of Colleague
implementations: MemberOfParliament, and
PrimeMinister (PrimeMinister is actually a
subclass of MemberOfParliament, so it too is a
Colleague). By having each Colleague aware of
the Forum they're participating in, they can send messages
without actually referencing one another.
Related Patterns
A few other design patterns are closely related to the Mediator pattern, and are often used in conjunction with it.
- Facade: "Provides a unified interface to a set of interfaces in a subsystem. Facade defines a higher-level interface that makes the subsystem easier to use." (Gamma et al., 1995) In more simplified terms, the facade pattern provides unidirectional communication with subsystem classes. Mediator is multidirectional.
- Observer: colleagues may communicate with a mediator using the observer pattern. In fact, this is very commonly used in conjunction with the Mediator, as it provides a facility by which the Colleagues may 'subscribe' to the Mediator, and thus alleviates the Mediator of the responsibility of having to know exactly what classes need to be informed of events.
Known Uses
In the following sections, we'll discuss some real-world uses of the Mediator pattern. You'll find the Mediator in many situations where there are many components that must interact with one another in complex ways.
User Interfaces
Perhaps the most common use for the Mediator pattern we've come across, is that in graphical user interfaces (Gamma et al., 1995), where a change in one control, may change the state of other controls. Instead of having the instantiating control know about all other possible controls that may need to know about changes, we
Java Message Service
Another use for the Mediator pattern is in messaging services between remote applications. For instance, the J2EE Java Message Service (Armstrong et al., 2004) provides applications with the ability to subscribe, and publish data to other applications in an asynchronous manner. Clearly, this is a variation of the Mediator, as it incorporates the Observer pattern for providing the publish and subscribe functionality, but this is a very common variation, and is worth mentioning.
Previous Experience
Our most common encounter with the Mediator pattern thus far has surely been in writing user interfaces; a task that dictates the use of many objects that often need to communicate with one another.
As mentioned earlier, the
Mediator is well suited for coordinating changes between related
controls in graphical user interfaces, and we would tend to agree.
Instead of placing the code that deals with 'notifying' other controls
of changes within the controls themselves, we've often found ourselves
creating 'notification' methods within the container class, such as
notifyFontChange(), that actually execute the various
methods required to update the appropriate controls. This has helped
us to reduce duplication of code, made changes to the UI far less
painful, and made the code itself far easier to understand.
Conclusion
It would be difficult for us to deny the sheer simplicity and usefulness of the Mediator pattern. By providing the loose coupling between Colleague objects and centralizing the interaction logic in the Mediator, changes are more easily facilitated, and code clarity is heightened.
While we haven't encountered this yet ourselves, we can easily foresee Mediator implementations becoming very large and complex when it must deal with a very large or unknown set of Colleagues. In such cases, we feel that using the Observer pattern would actually help a great deal, by placing the interaction logic back into the Colleagues. Colleagues in this case would then publish and subscribe to events that affect them, and would deal these events themselves. The Mediator would then only provide the means by which Colleagues may inform one another of such events. Such a Mediator is actually provided by the Java Message Service, as we mentioned earlier.
References
Contact Information
Please feel free to contact one of us should you have any questions about the Mediator design pattern:
- Andrea Friedrich: software_engg_student@REMOVE_THIShotmail.com
- Clarice Ho: ccyho@REMOVE_THISucalgary.ca
- Dave Heaton: daveheaton@REMOVE_THISshaw.ca
You may also download a copy of this website, and related materials.