This lesson follows Iterator. Mediator addresses communication among components rather than traversal.

Mediator centralizes how a group of components cooperates. Components depend on the mediator contract instead of each other. The cost is moving coupling into the coordinator, which can grow too large.

Extract the relationships that block reuse

A shipping checkbox reveals an address field. A submit button checks that field before saving. If the checkbox and button call each other and the field directly, each reusable control carries rules for one particular form.

type DialogEvent = "shippingChanged" | "submit";
interface Mediator { notify(event: DialogEvent): void }
class ShippingCheckbox {
  checked = false;
  constructor(private mediator: Mediator) {}
  toggle(checked: boolean) {
    this.checked = checked;
    this.mediator.notify("shippingChanged");
  }
}
class AddressField { visible = false; value = ""; }
class SubmitButton {
  constructor(private mediator: Mediator) {}
  click() { this.mediator.notify("submit"); }
}
class ShippingDialog implements Mediator {
  readonly shipping = new ShippingCheckbox(this);
  readonly address = new AddressField();
  readonly submit = new SubmitButton(this);
  notify(event: DialogEvent): void {
    if (event === "shippingChanged") {
      this.address.visible = this.shipping.checked;
    } else if (this.shipping.checked && !this.address.value.trim()) {
      console.log("Address required");
    } else {
      console.log("Save form");
    }
  }
}

The controls know the Mediator interface. ShippingDialog knows the controls and the form rules. These controls still use shipping-specific events. A broader reusable control library would use a generic event contract with a sender or typed payload.

Follow an event through the coordinator

Keep the coordinator bounded

Map the roles

Components must not know about each other. When something important happens to a component, it only tells the mediator. To a component, the mediator is a black box: the sender does not know who handles its event, and the receiver does not know who sent it.

Role	In this example	Job
Components	ShippingCheckbox, AddressField, SubmitButton	Classes with business logic. Each holds a reference to the mediator, typed as the mediator interface, so it can be reused with a different mediator.
Mediator	Mediator	Declares how components communicate with it. Usually a single notification method, which can carry context such as the sender.
Concrete mediator	ShippingDialog	Encapsulates the relations between components. Often keeps references to all the components it manages, and sometimes controls their life cycle.

Reach for it when components are tangled with their peers

• some classes are hard to change because they are tightly coupled to many other classes. Extract all the relationships into a separate class, so a change to one component stays isolated from the rest.
• you cannot reuse a component in another program because it depends too much on other components. After applying Mediator, components do not know about each other. To reuse one in a new app, give it a new mediator class.
• you are creating many component subclasses just to reuse basic behavior in different contexts. All relations between components live in the mediator, so you can define new ways for components to collaborate with a new mediator class, without touching the components.

Implement it in six steps

Refactor existing code toward the pattern in this order:

1. Identify a group of tightly coupled classes that would benefit from being more independent, for example to make them easier to maintain or reuse.
2. Declare the mediator interface and the communication protocol between mediators and components. In most cases, one method for receiving notifications is enough. This interface is what lets you reuse components in different contexts.
3. Implement the concrete mediator. It benefits from storing references to all the components it manages.
4. Optionally, make the mediator responsible for creating and destroying components. It then starts to resemble a factory or a facade.
5. Give each component a reference to the mediator, usually set in the component's constructor.
6. Change the components so they call the mediator's notification method instead of methods on other components. Move the code that calls other components into the mediator, and run it when the mediator receives a notification.

Name what it costs

You gain	You pay
Communication between components lives in one place, easier to understand and maintain (single responsibility)	Over time the mediator can grow into a god object
New mediators without changing the components (open/closed)	Events need a stable contract
Less coupling between components	Feedback loops are possible when a reaction triggers another notification
Individual components are easier to reuse

Do not confuse it with its neighbors

Pattern	How it relates
Chain of Responsibility, Command, Observer	All four connect senders and receivers differently. Mediator removes direct connections between senders and receivers and forces them to talk through a mediator object.
Facade	Both organize collaboration among tightly coupled classes. A facade defines a simple interface to a subsystem, adds no behavior, and the subsystem does not know it exists. A mediator centralizes communication, and components know only the mediator.
Observer	The difference is easy to blur. Mediator's goal is to remove mutual dependencies among a set of components, which all depend on one mediator. Observer's goal is dynamic one-way connections, where some objects act as subordinates of others. A popular Mediator implementation uses Observer: the mediator publishes, and components subscribe. A mediator can also link components permanently, with no subscriptions at all. And a program where every component publishes to every other has no mediator, only distributed observers.

Retrieve and apply

Move one form rule from a reusable control into its coordinator. Continue to Memento to save private state without exposing it to history code.