Mediator

Pattern Properties

Type: Behavioral

Level: Component

Purpose

To simplify communication among objects in a system by introducing a single object that manages message distribution among the others.

Introduction

A useful feature in the PIM would be sharing information among several users, so that one user could set up a meeting that other PIM users would attend. With a shared set of data, all the participants would be up-to-date on the meeting plans.

How should you manage the appointments, assuming multiple PIMs are running? One way is to give each PIM a copy of the Appointment object, ensuring that they have local access to the data. This presents a problem: how do you ensure that information is consistent among all users? For example, if the user creates a meeting and later changes the date, how do the other meeting participants find out?

You can make the user's application responsible for managing the update. However, if any of the meeting participants are allowed to make updates, that means that each PIM has to keep track of all of the other PIMs. Managing communication for a large number of participants becomes very difficult. In the best case, it is inefficient and costly in terms of network bandwidth; in the worst case, the planning for a meeting degenerates into chaos. And generally, you’d prefer to leave the chaos to the meetings themselves.

Given the potential complexity of the system, it’s better to delegate the task of sending and receiving specific requests to a central object, which then makes decisions about what methods to call. This is the essence of the Mediator pattern. Instead of making the

Appointment itself responsible for sending updates, create an AppointmentMediator. Each time Appointment changes, call a method in the Mediator object, which might decide to call methods on the Location object to confirm. Depending on the result, the AppointmentManager broadcasts the original message, a revised version of the message such as a meeting time change, or a cancellation.

Applicability

Use Mediator when:

There are complex rules for communication among objects in a system (often as a result of the business model).

You want to keep the objects simple and manageable.

You want the classes for these objects to be redeployable, not dependent on the business model of the system.

Description

As communication among objects in an application becomes more complex, managing communication becomes more and more difficult. Handling event processing for a simple spreadsheet control might involve writing code for the grid component. However, if the GUI is expanded to include a grid, graph, and record-display fields, it becomes much more difficult to manage the code. A change in one of the components might trigger changes in some or all of the others.

The Mediator pattern helps solve this problem, since it defines a class that has overall communications responsibility. This greatly simplifies the other classes in the system, since they no longer need to manage communication themselves, and that can help you keep much of your hair and your sanity. The mediator object—the central object to manage communication—has the role of a router for the system, centralizing the logic to send and receive messages. Components send messages to the mediator rather than to other components of the system; likewise, they rely on the mediator to send change notifications to them.

Consider implementing Mediator whenever a set of GUI components should behave as a whole. The main factor in deciding whether to implement the pattern is the overall complexity of the GUI model. Two other possible scenarios for Mediator implementation are:

57