Mediator Pattern

Route all communication between a group of objects through one coordinator, so the objects know the coordinator and not each other.

Overview

The problem: everyone talks to everyone

A checkout form has a country dropdown, a state dropdown, a postal code field, a shipping-method list and a Pay button. Change the country, and the state list must reload, the postal code must re-validate, shipping options must change, and the button must disable until the form is valid again. If each widget calls the others directly, every widget ends up holding references to most of the rest.

The number of possible pairs grows fast. With n objects there are n(n-1)/2 pairs.

5 — 10 — 5
10 — 45 — 10
20 — 190 — 20

Every direct link is a reason one class cannot be changed, tested or reused without another. The Mediator pattern replaces the web with a star.

The pattern

Mediator is one of the 23 patterns in the 1994 Gang of Four book (Gamma, Helm, Johnson and Vlissides). The objects that used to talk to each other are the colleagues. They keep one reference each, to the mediator, and report what happened to it. The mediator holds the rules about who reacts to what, and calls the right colleagues.

A runnable example

A chat room is the classic example. Users send to the room, and the room decides who receives: everyone else, minus anyone the recipient has muted.

Adding a rule such as room-wide slow mode or a moderator broadcast changes ChatRoom.send and nothing in User. That is the pattern working.

Mediator, Observer and Facade

These three are often confused because each puts an object between other objects. They differ in direction and in who holds the logic.

Shape — Many to many, through a hub — One to many, broadcast — One simple front over a subsystem
Who decides who reacts — The mediator, by rule — Nobody; every subscriber gets every event — Not applicable; callers call the facade
Do participants talk back — Yes, both ways — No, subject to observers only — No, the subsystem does not call the facade
Holds business rules — Yes, that is its job — No — No, it only simplifies calls

A stock ticker that notifies all subscribers is Observer. A form where changing one field enables or disables others by rule is Mediator. Many mediators are built on Observer inside: the colleagues publish events, and the mediator is the one subscriber that then acts.

The risk: a mediator that knows too much

Everything the colleagues stopped knowing, the mediator now knows. That is the trade, and it can go wrong.

The mediator is the largest class in the module — Business logic moved into it along with the routing — Keep only who-reacts-to-what in the mediator; put the work back in the colleagues or in services
Every feature change edits the mediator — One mediator for the whole screen or system — Split by concern: one mediator per dialog, per workflow
Rules refer to colleagues by name everywhere — Colleagues are concrete fields — Have colleagues publish named events; let the mediator map events to reactions
Hard to test — The mediator builds its colleagues — Inject colleagues; test the mediator with fakes

What you will be able to do

Recognize a many-to-many object web and say why it is expensive to change.
Draw the star, and explain what a colleague is allowed to know.
Write a mediator whose rules are in one place and whose colleagues are reusable.
Separate Mediator from Observer and Facade in one sentence each.
Name the god-object risk before the interviewer does, with the remedy.

Interview questions

Show the smell Mediator fixes, and the fix.
How is Mediator different from Observer?
How do you keep the mediator from becoming a god object?
How do colleagues get their mediator, and how do you test them?