design patterns · medium

Mediator Pattern

Mediator is a behavioral GoF pattern that defines an object encapsulating how a set of objects interact, promoting loose coupling by keeping them from referring to each other explicitly. When N components each talk directly to several peers you get an O(N²) tangle where every component knows many others and changes ripple everywhere; Mediator routes all communication through one hub, turning a many-to-many mesh into hub-and-spoke. Each component holds a pointer to the mediator and merely notifies it of events (m_->notify(this, event)) without deciding what happens to its peers; the concrete mediator (e.g. a LoginDialog) receives every notification and contains all the coordination logic — when the guest checkbox toggles, the mediator enables/disables the username, password, and OK widgets. Interaction rules can be read and changed in one place, and the now-dumb components become reusable and testable in isolation. Pros: decoupled components, centralized control, reusability. The main con is that the mediator can become a god object as all the previously distributed complexity concentrates in one class. It differs from a Facade (a one-way simplified front the subsystem is unaware of) because a Mediator is bidirectional and actively coordinates its components, and from Observer (a one-to-many broadcast of a subject's change to passive listeners) because Mediator manages mutual, many-directional interactions with the rules held in the hub. Use it when components are tightly interlinked and you want to decouple them — UI dialogs, chat rooms, air-traffic control — while watching the god-object risk.

The code

// Mediator — components talk to ONE hub, not to each other. Turns a
// tangled many-to-many web into a clean hub-and-spoke (star).
struct Mediator {
    virtual void notify(Widget* sender, Event e) = 0;
};

struct Widget {
    Mediator* m_ = nullptr; // knows only the mediator
    void changed(Event e) {
        if (m_)
            m_->notify(this, e);
    }
};

// The mediator centralizes ALL the interaction rules:
class LoginDialog : public Mediator {
    CheckBox guest_;
    TextBox user_, pass_;
    Button ok_;

public:
    void notify(Widget* s, Event e) override {
        if (s == &guest_) { // one place owns the wiring
            bool on = guest_.checked();
            user_.setEnabled(!on); // mediator coordinates peers
            pass_.setEnabled(!on);
            ok_.setEnabled(on || user_.nonEmpty());
        }
    }
};
// Widgets never reference each other — only the LoginDialog does.

What this lesson walks through

1. 01Intent — replace a tangled web with a hub
2. 02Structure — colleagues talk only to the mediator
3. 03One change, the mediator coordinates the rest
4. 04Gotcha — the mediator god-object

When many objects each reference many others, you get an N×N web that is impossible to change. Mediator introduces a central hub: each colleague talks ONLY to the mediator, turning N×N links into N.