Deep Dive
low level designdesign patternsoop

Mediator Pattern: Turn a Mesh of Dependencies Into a Star

When every object holds a reference to every other, change becomes impossible — an O(N²) tangle where one edit ripples everywhere. The Mediator pulls the wiring into one place so components can stay gloriously ignorant of each other.

·15 min read
Medium

The booking dialog started with two fields. Pick a destination, pick dates, the Book button lights up. Easy enough: the destination field, on change, checks the dates field and toggles the button. So the destination field now holds a reference to the dates field and to the button.

Then product wanted the dates field to clear the destination when you switch to a round-trip. So dates got a reference back to destination. Then a promo-code field appeared that disables Book while it validates, and re-enables it on success — so it too reaches into the button, and into a spinner, and reads the destination to decide whether the promo even applies. Six controls in, every widget holds references to three or four others, and the “did this field change that field” logic is smeared across all of them. Nobody can add a seventh control without reading all six, because any of them might be poking the one you’re adding.

The number of widgets isn’t the problem. The problem is the wiring: with N controls each talking to the others directly, you have up to N·(N−1) references to keep straight — a mesh that grows quadratically and lives nowhere in particular. The Gang of Four named the untangle.

The intuition: the control tower

Picture an airport with no tower. Every pilot would have to negotiate directly with every other pilot in the airspace — “I’ll take runway two if you hold at the gate” — a shouting match that gets exponentially worse with each plane. It doesn’t scale, and it isn’t safe.

So airspace has a control tower. No plane talks to another plane. Each one talks only to the tower, and the tower — which alone holds the full picture of who’s landing, who’s holding, who’s cleared — choreographs the whole ballet. Add a plane and you don’t retrain every pilot; you just put it on the tower’s frequency.

The planes are the colleagues. The tower is the mediator. The colleagues stay simple precisely because all the coordination complexity was lifted out of them and concentrated in one place that owns it on purpose.

Why it exists: the mesh becomes a star

Count the edges. With direct references, N components form a mesh — up to N·(N−1) directed connections, every one a coupling you must understand before you touch anything. Route all of it through a mediator and the topology collapses to a star: N components, each with exactly one edge (to the mediator). Linear, not quadratic. That’s the whole trade — you pay for one central object and buy back the ability to reason about, and change, each component alone.

ABCDEAMediatorBCDE
Left: five peers wired directly — a mesh whose edge count grows quadratically. Right: the same five routed through a mediator — a star, one edge each. The mediator absorbs the coupling so the peers don't have to.

The star’s edges all point at the middle. That single indirection is what lets you add colleague F — a sixth control, a fourth chat user — by giving it one reference to the mediator and teaching the mediator one new rule, while every existing colleague stays frozen.

From here the members-only continuation builds the pattern for real: the annotated chat-room and booking-dialog code where colleagues talk only to the mediator, the two-role class structure, the god-object failure mode with the Mediator-vs-Observer-vs-Facade distinctions, real systems that are secretly mediators, the full tradeoff card, and an interview corner with a smart-home refactor challenge and a quiz.

Members only

Keep reading with Premium

You've reached the members-only part of this deep-dive — the full implementation, the interactive ring simulator, and the step-by-step walkthrough. Unlock it with a membership.

Related Articles