Design Pattern: Mediator

The Mediator defines an object that controls how a set of objects interact. Loose coupling between colleague objects is achieved by having colleagues communicate with the Mediator, rather than with each other. Many a times in projects communication between components are complex.Due to this the logic between components becomes very complex. Mediator Pattern helps the objects to communicate in a disassociated manner, which leads to minimizing complexity.

Say that you’ve got a four-page Web site that lets users browse a store and make purchases. As things stand, the user can move from page to page. But there’s a problem — the code in each page has to know when to jump to a new page as well as how to activate the new page. You’ve got a lot of possible connections and a lot of duplicate code in the various pages.

You can use a mediator here to encapsulate all the navigation code out of the separate pages and place it into a mediator object instead. From then on, each page just has to report any change of state to the mediator, and the mediator knows what page to send the user to.  You can build the mediator to deal with the internals of each page so the various pages don’t have to know the intimate details of the other pages (such as which methods to call). And when it’s time to modify the navigation code that takes users from page to page, that code is all collected in one place, so
it’s easier to modify.

Illustration: Problem

Consider the implementation of dialog boxes in a GUI.  A dialog box uses a window to present a collection of widgets such as buttons, menus, and entry fields, as shown here.

Often there are dependencies between the widgets in the dialog. For example a button gets disabled or enabled when a certain entry in a list of choices of list box is selected .

Different dialog boxes will have different dependencies between widgets. So even though dialogs display the same kinds of widgets, they can’t simply reuse stock widget classes; they have to be customized to reflect dialog-specific dependencies. Customizing them individually by subclassing will be tedious, since many classes are involved.

Illustration:Solution

We can avoid previous said problem by encapsulating collective behavior in a separate mediator object. A mediator is responsible for controlling and coordinating the iterations of a group of objects. The mediator serves as an intermediary that keeps objects in the group form referring to each other explicitly. The objects only know the mediator, thereby reducing the number of interconnection

FontDialogDirector can be mediator between the widgets in a dialog box.

A FontDialogDirector object knows the widgets in a dialog and coordinates their interaction.

It acts as a hub of communication for widgets

 

In the above model notice who the director communicates with list box and entry field. Widgets communicate with each other only indirectly, through the director. All they know is the director and they in turn don’t know each other.

Furthermore, because the behavior is localized in one class, it can be changed or replaced by extending or replacing that class

Here’s the succession of events by which a list box’s selection passes to an entry field:

The following interaction diagram illustrates how the objects cooperate to handle a change in a list box’s selection.

1. The list box tells its director that it’s changed

2. The director gets the selection form the list box

3. The director passes the selection to the entry field

4. Now that the entry field contains some text, the director enables button(s) for initializing an action ( e.g. ‘demibold’,’oblique’

Applicability

Use the Mediator pattern when:

1. a set of objects communicate in well-defined but complex ways . The resulting interdependencies are unstructured and difficult to understand.
2. reusing an object is difficult because it refers to and communicates with many other objects.
3. a behavior that’s distributed between several classes should be customizable without a lot of sub classing.

 

Collaborations

Colleagues send and receive requests form a Mediator object. The mediator implements the cooperative behavior by routing between the appropriate colleague(s).

Consequences

1. It limits subclassing: mediator localizes behavior that otherwise would be distribured among various objects. Changing this behavior requires subclassing Mediator only; Colleagure classes can be reused as it is.
2. It decouples colleagues:
3. It simplifies object protocols: A one to many relationships are easier to understand, maintain, and extend. Thus mediator replaces many to many interactions with one-to-many interactions between the mediator and its colleagues.
4. It abstracts how objects cooperate:
5. It centralizes control: