Mediator

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." 

You will find on this page, a detailed, and hopefully useful, investigation into the various aspects of this relatively simple, yet powerful design pattern.

Back to top.

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 .

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.

Back to top.

Structure

Expressed in UML, a Mediator pattern may be structured with a handful of simple classes and interfaces (Figure 1.).

Figure 1: Mediator Structure

So an example implementation, in the context of the air traffic controller described earlier, could also be structured in UML (Figure 2.).

Figure 2: Air Traffic Controller Example Structure

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.).

Figure 3: Air Traffic Controller Example Sequence Diagram

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.

Back to top.

Participants

There are three participants in the Mediator pattern (Figure 1.):

• Mediator: defines an interface for communicating with Colleague objects.
• 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 .
• Colleague classes: each Colleague class knows its Mediator object, and communicates with it whenever it would have otherwise communicated with another Colleague .

Applicability

According to Gamma et al, the Mediator pattern should be used when:

• 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. 
• 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".

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, 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.