Mediator

Mediator is a behavioral pattern that reduces chaotic dependencies between objects by introducing a central object that handles their interactions. Instead of components talking directly to one another, they talk to the mediator, which coordinates the conversation. This converts a tangled many-to-many web of references into a star topology centered on the mediator.

How It Works

A mediator interface declares the methods components use to communicate, such as notify(sender, event). A concrete mediator knows all participating colleagues and implements the coordination logic; when one colleague raises an event, the mediator decides which others to update and how. Colleagues hold a reference only to the mediator, not to each other, so they become reusable and ignorant of the broader workflow.

The coordination logic that would otherwise be scattered across components is consolidated in one place. This makes the interaction rules easy to find and change, at the cost of concentrating complexity in the mediator.

When to Use It

Use Mediator when a set of objects communicate in well-defined but complex ways and the resulting dependencies are hard to understand, when reusing a component is difficult because it refers to many others, or when behavior distributed across several classes should be customizable without subclassing all of them. Dialog boxes, form validation, air-traffic-style coordination, and chat rooms are classic examples.

Trade-offs

The mediator can grow into a god object that knows too much and becomes a maintenance bottleneck, the very monolith the pattern was meant to avoid. Splitting one large mediator into several focused ones mitigates this. Centralization also adds a layer of indirection that can obscure simple flows. When interactions are few and stable, direct references are clearer than a mediator.

Related Patterns

Observer also decouples objects, but it broadcasts state changes from a subject to many observers, whereas Mediator encapsulates how a specific set of objects cooperate, often using Observer internally to receive their notifications. Facade provides a simplified interface to a subsystem but does not add new coordination behavior the way a mediator does. Command can represent the requests colleagues send through the mediator. At the architecture scale, an event bus or message broker plays a mediator-like role between services, and the air-traffic-control metaphor that gives the pattern its name captures the intent: aircraft never coordinate directly with each other but route every instruction through a central controller.

Example

A flight booking form has fields for origin, destination, dates, and a fare display. Rather than each field updating the others, all of them report changes to a BookingMediator. When the destination changes, the mediator clears incompatible dates, disables sold-out cabins, and refreshes the fare. Fields stay simple and reusable, and the booking rules live in one coordinating class that can be tested on its own. The same approach tames complex dialog boxes, wizard flows where later steps depend on earlier answers, and chat rooms where a room mediator relays each message to the right participants. When the single mediator grows unwieldy, it is split into smaller mediators by responsibility so no one class owns the entire interaction surface.