Mediator

The three participants

A textbook Mediator has three roles, and the discipline that makes it work is brutally simple: colleagues hold a reference to the mediator and nothing else.

• Mediator interface — declares how colleagues talk to the hub, typically one method like send(message, from). Colleagues depend only on this interface, so you can swap in a different concrete mediator (a logging room, a moderated room) without touching them.
• Concrete Mediator (ChatRoom, the control tower) — keeps the list of colleagues and owns all the coordination logic: who receives what, in what order, under what rules. This is the one place where 'who talks to whom' lives.
• Colleagues (User, a plane) — each holds a single reference to the mediator. To communicate, a colleague calls the mediator; to be reached, it exposes a method the mediator calls back (like receive()). A colleague never names another colleague.

The connection math

This is the heart of the pattern. Fully meshed, n colleagues need n(n−1)/2 links, because every pair gets its own connection — and every existing object changes when a new one joins, since each must learn about the newcomer. With a hub, n colleagues need exactly n links, and a newcomer costs exactly one new link — registration with the mediator. Nobody else is edited, recompiled, or even aware.

There's a second, quieter win: colleagues become reusable. A User class that hard-codes ben.receive(...) and chloe.receive(...) can only live in this exact chat. A User that only knows 'some mediator' can be dropped into any room, any test harness, any future feature — because it never names its peers. Low coupling between colleagues is bought by pointing all the coupling at one hub (see [[coupling-and-cohesion]]).

interface ChatMediator {                 // the Mediator interface
  send(message: string, from: User): void;
}

class ChatRoom implements ChatMediator { // the concrete mediator (the tower)
  private users: User[] = [];

  join(user: User) { this.users.push(user); }   // one link per newcomer

  send(message: string, from: User) {
    // ALL routing logic lives here — colleagues know none of it
    for (const u of this.users) {
      if (u !== from) u.receive(message, from.name);
    }
  }
}

class User {                             // a colleague
  constructor(public name: string, private room: ChatMediator) {}
  send(message: string)  { this.room.send(message, this); } // talk to the hub only
  receive(message: string, from: string) {
    console.log(`${this.name} got "${message}" from ${from}`);
  }
}

Trace one message: Ana calls ana.send("hi") → her User object forwards to room.send("hi", ana) → the ChatRoom loops over its member list and calls receive() on everyone but Ana. Ana's class contains no mention of Ben, Chloe, or Dan. Add Eve tomorrow with one room.join(eve) call — Ana's code doesn't change by a single character.

Where you've already met it

• UI dialogs — the GoF's original example. A dialog box coordinates its widgets: when the 'signup' checkbox is ticked, the dialog enables the email field and relabels the button. The checkbox doesn't poke the text field directly; the dialog (mediator) reacts and coordinates.
• Air traffic control — the physical-world mediator. Planes broadcast position and intent to the tower; the tower sequences landings. No pilot-to-pilot negotiation.
• Chat servers — Slack, Discord, IRC. Your client never opens a socket to every other member of a channel; it talks to the server, which routes to the room.
• Event buses / message brokers — components publish events to a bus and subscribe to what they care about, never referencing each other. Pub/sub is Mediator's looser cousin: same hub shape, but the hub routes by topic instead of by bespoke coordination rules.

Mediator vs Observer — the classic mix-up

Both patterns decouple objects that need to react to each other, so they're easy to confuse. [[observer]] is one-to-many broadcast from a subject: one object announces 'I changed', and whoever subscribed gets notified — the subject doesn't know or care what listeners do. Mediator is many-to-many coordination through a hub: a whole group of peers communicate, and the hub owns the rules of the conversation — who hears what, in what order, under what conditions. A handy tell: in Observer the interesting logic lives in the listeners; in Mediator the interesting logic lives in the hub. (In practice a mediator is often implemented using observer-style callbacks — the patterns compose.)

Reach for a Mediator when the links themselves are the problem

• Widgets or components with tangled cross-references — a form where the checkbox enables a field, the field validates against a dropdown, the dropdown relabels a button. Move the choreography into one dialog/controller mediator and each widget shrinks back to doing its own job.
• You want to reuse colleagues independently — a class you can't lift out of its context because it names five sibling classes isn't reusable. Route everything through a mediator and the colleague travels light: it only needs a hub, any hub.
• Complex interaction rules that deserve one home — 'when X happens, tell Y unless Z is busy' scattered across ten classes is unfindable. In a mediator, the whole conversation policy sits in one readable place you can test on its own.
• The group's membership changes at runtime — chat rooms, plugin systems, planes entering airspace. With a hub, joining and leaving is one registration call instead of introducing the newcomer to every peer.