The middleman that reduces connections

Why does adding something in the middle leave fewer links than before, not more?

A dialog has a dozen controls that must react to each other: selecting a country reloads the region list, which enables the postcode field, which changes the validation on the address, which enables the submit button. Each rule is written where it belongs — in the control that knows about it — and the whole thing gradually becomes unmaintainable.

Someone proposes adding another object to the design. Adding a component to a system that is already too tangled sounds like the wrong direction entirely. Yet done properly it leaves fewer connections than before, not more. That is a claim about arithmetic, and the arithmetic is worth doing carefully, because it is the only reason the pattern is worth its costs.

Count the links. If every one of n components may talk to every other, the number of distinct pairs is n(n-1)/2. For three components that is three — unremarkable. For six, fifteen. For twelve, sixty-six. The count grows with the square of the parts, so the tangle does not get worse gradually; it gets worse at an accelerating rate, and the point at which a design stops feeling manageable arrives suddenly.

Now route everything through one object in the middle. Each component knows exactly one collaborator — the mediator — and the mediator knows all of them. That is n links, plus one object. So we added a part and removed edges, and the arithmetic says the trade turns favourable as soon as n(n-1)/2 exceeds n, which happens at n = 3 and grows overwhelming from there. At twelve components it is sixty-six links against twelve.

But before accepting that, ask the harder question: was the coupling removed, or moved? Moved. The knowledge of how the controls interact did not evaporate; it now lives inside the mediator, which is by construction the one object that must know everything. What changed is the shape of the dependency graph, not the total amount of knowledge in the system.

Is a change of shape worth anything on its own? Consider what each is like to work with. In the tangled version, the rule "selecting a country clears the postcode" is written inside the country control, so the country control cannot be reused or tested without the postcode field existing. Every component is a partial description of the whole dialog. In the mediated version, each control knows only how to report what happened to it and how to respond to instructions — so it is reusable and testable alone, and the interaction rules are all in one file where they can be read as a set. Concentrating knowledge in one honest place beats smearing it across twelve that each hold a fragment.

That points straight at the pattern's known failure. The mediator becomes a god object: it accumulates every rule, grows to thousands of lines, and turns into the thing everyone is afraid to touch. The pattern does not prevent this; it merely makes the problem visible in one file instead of invisible across twelve. The mitigation is to split by cohesion — several mediators for genuinely separate clusters of interaction — and to keep the mediator making decisions rather than doing work.

Two honest qualifications about the arithmetic itself.

First, n(n-1)/2 is a worst case, not a description. Real systems are rarely fully connected; a component typically talks to two or three neighbours, not to all of the others, so the true saving is smaller than the quadratic bound suggests. The bound tells you how bad it can get, which is the right thing to design against, but quoting it as the actual count overstates the case.

Second, the mediator adds a hop. Every interaction now travels through an extra object, which costs a little indirection at run time and a lot of traceability at debug time — "who caused this to happen" becomes a question you answer by reading the mediator rather than by following a direct call.

Notice, finally, that this same arithmetic is the whole argument for several much larger things. A message broker is a mediator between services; a network switch is one between hosts; an integration hub is one between applications. Each is defended with the identical n-squared-to-n argument, and each inherits the identical hazard of becoming the component that knows too much and cannot fail.

Three refinements.

The mediator is not an event bus, though the two are often confused. A mediator knows its participants and decides what should happen; an event bus knows nobody and simply broadcasts. That difference decides where the interaction logic lives — centralised and readable in the first case, distributed among subscribers in the second, which is the tangle again in a different costume.

The saving is in the count of relationships, not in the amount of code. You will typically write about as much logic as before, sometimes slightly more. What you buy is that each component can now be understood, tested and replaced without reference to its peers.

And the pattern is not free at small n. Below three or four interacting parts the direct links are fewer than the mediated ones and much easier to follow. Introducing a mediator into a two-component interaction is pure ceremony, and it is a common way for a simple design to acquire an unnecessary layer.

• When to split one mediator into several, and what signals the split.
• Mediator versus event bus, and why the choice decides where interaction logic lives.
• The same arithmetic at infrastructure scale: brokers, switches, and integration hubs.

Every term the collection defines is gathered in the glossary.