Mediator Pattern

1The problem it solves#

Start with the mess the pattern is meant to kill: too many objects knowing too much about each other.

Picture a chat room with five users. Each user needs to send messages to every other user.

• If each User holds a direct reference to the other four, you get a dependency graph shaped like spaghetti.
• Add a sixth user and you wire up five more references.
• This is the classic many-to-many mess, and it grows like n squared: 5 users is 20 directed edges, 10 users is 90, 50 users is 2,450.
• The wiring cost explodes long before the feature list does.

Now add a rule and watch it get worse. Say a message should be logged, filtered for profanity, and skipped if the recipient has blocked the sender.

• If each User talks to each other User directly, that policy gets copy-pasted into every object, or smeared across all of them.
• Change one rule and you are hunting through every class to patch the same three lines.

I have seen this exact shape in real code. UI forms where a checkbox enables a text field, which changes a dropdown, which disables a button.

• Every widget knows about three other widgets.
• Touch one and something unrelated breaks two screens away.

The root cause is coupling, and the Mediator answer is blunt: the objects should not talk to each other at all.

• They talk to one object in the middle, and that object decides what happens next.
• This is the Single Responsibility Principle applied to interaction: "who talks to whom, under what rules" becomes one object's job.
• It is also Dependency Inversion: colleagues point at a Mediator interface, never at concrete peers.

2The idea (mental model)#

The cleanest picture here is an air traffic control tower.

• Planes do not radio each other to coordinate landings. That would be chaos.
• Every plane talks only to the tower, and the tower tells each plane what to do.
• The planes do not even know the other planes exist. They just know the tower.

That is the whole pattern.

• The planes are your Colleague objects. The tower is the Mediator.
• Instead of a web of connections, you get a star: everything points to the center, and the center points back out.
• The edge count drops from n squared to n.

The key shift in thinking: a colleague gives up control of the interaction.

• A colleague no longer says "send this message to Bob."
• It says "here is a message, Mediator, you figure out where it goes."
• The colleague owns the what. The mediator owns the how.
• Result: n-to-n relationships become n-to-1, and you get a single place to put interaction rules.

3Structure#

Four roles, and the asymmetry between them is the point.

• Mediator (interface). Declares how colleagues notify it, usually something like notify(sender, event).
• ConcreteMediator. Holds references to all the colleagues and contains the actual coordination logic. This is where the brains live.
• Colleague (abstract or interface). Each colleague holds a reference to the mediator and nothing else about its peers.
• ConcreteColleague. The real objects (users, widgets, planes). They report events up to the mediator and react to calls coming down.

The asymmetry in one line: the colleagues are dumb about each other, the mediator is smart about all of them.

4Implementation in Java#

Here is a chat room. Minimal, but it shows every role.

interface Mediator {
    void send(String message, User sender);
    void register(User user);
}

abstract class User {
    protected Mediator mediator;
    protected String name;

    User(Mediator mediator, String name) {
        this.mediator = mediator;
        this.name = name;
    }

    public void send(String message) {
        mediator.send(message, this);
    }

    public abstract void receive(String message, String from);
}

class ChatUser extends User {
    ChatUser(Mediator mediator, String name) {
        super(mediator, name);
    }

    @Override
    public void receive(String message, String from) {
        System.out.println(name + " got from " + from + ": " + message);
    }
}

class ChatRoom implements Mediator {
    private final List<User> users = new ArrayList<>();

    @Override
    public void register(User user) {
        users.add(user);
    }

    @Override
    public void send(String message, User sender) {
        // All the interaction rules live HERE, in one place.
        for (User u : users) {
            if (u != sender) {
                u.receive(message, sender.name);
            }
        }
    }
}

Wiring it up:

Mediator room = new ChatRoom();
User alice = new ChatUser(room, "Alice");
User bob = new ChatUser(room, "Bob");
User carol = new ChatUser(room, "Carol");

room.register(alice);
room.register(bob);
room.register(carol);

alice.send("hey everyone");
// Bob and Carol receive it. Alice never touched them directly.

Now watch how cheap it is to add a rule. Want to block profanity, skip muted users, or log every message?

• You change ChatRoom.send. One method.
• The User classes do not move at all.
• That is the payoff for all the indirection.

@Override
public void send(String message, User sender) {
    String clean = filterProfanity(message);
    audit.log(sender.name, clean);
    for (User u : users) {
        if (u != sender && !isMuted(sender, u)) {
            u.receive(clean, sender.name);
        }
    }
}

5A real-world example#

The one I hit most often is a complex form or dashboard.

Think of a flight booking screen with a "round trip" toggle, a return-date picker, a passenger count, and a "search" button. The rules are tangled:

• Checking "one way" should gray out the return date.
• Zero passengers should disable search.
• Picking a date in the past should show a warning.

Without a mediator, the widgets reach into each other.

• The checkbox listener reaches into the date picker, the date picker reaches into the button.
• Six months later nobody can tell what enables what.

A FormMediator fixes this.

• Each widget reports "I changed" to the mediator.
• The mediator holds all the enable/disable logic in one onChange(widget) method.
• Widgets stay dumb. The rules stay in one readable place.

Same shape shows up at bigger scale.

• Message brokers and event buses: services publish to the bus, the bus routes, and no service holds a reference to any other service.
• Air traffic control, ride-hailing dispatch, and the coordination layer in a lot of game engines all lean on this idea.

Here is the runtime flow for the chat case, so you can see who talks to whom:

6When to use it, and when not to#

Use it when:

• You have a set of objects with many-to-many communication and the wiring is getting hairy.
• The interaction logic between objects is complex and you want it in one place you can read and test.
• You want to reuse a colleague in a different context by handing it a different mediator.

Skip it when:

• The communication is simple or one-directional. Two objects talking? Let them talk. A mediator there is ceremony for nothing.
• A natural hub-and-spoke already exists. If object A already owns B, C, and D, you may have your mediator without naming it.

The honest warning, and say it before you are asked: the mediator can swell into a god object.

• All the logic that moved out of the colleagues has to go somewhere, and it piles up in the middle.
• If your ChatRoom grows to 800 lines and knows every quirk of every colleague, you have traded a coupling problem for a complexity problem.
• That is a real tradeoff, not a free lunch.
• When the mediator gets fat, split it or introduce sub-mediators.

7Common mistakes#

Letting colleagues keep direct references to each other.

• This is the big one.
• If User still holds a pointer to another User "just for this one case," you have broken the pattern and kept all the coupling.
• The whole deal is that colleagues only know the mediator.

Turning the mediator into a dumping ground.

• The mediator should coordinate, not absorb every piece of business logic in the system.
• If it is doing validation, persistence, logging, and routing all inline, pull those into separate collaborators that the mediator calls.

Confusing it with Observer.

• They look similar because both decouple senders from receivers.
• Observer is one-to-many broadcast with no coordination logic: publishers do not care who listens.
• Mediator centralizes bidirectional coordination, with real decision-making in the middle.
• The test: if your central object makes routing decisions and enforces rules, it is a mediator. If it is just a notification firehose, it is observer.

Leaking colleague state through the notify signature.

• Keep the notify/send signature tight.
• The mediator should figure out what to do from the sender and a small event.
• If every colleague passes its full internal state up, your encapsulation is leaking.

8Where it shows up in interviews#

This pattern comes up constantly in design-a-chat-application and design-a-messaging-system prompts.

• The moment you say "users send messages," the follow-up is "how do they find each other?"
• The right answer is a chat room mediator, not users holding each other's references.

It also shows up anywhere a central controller coordinates independent units.

• Air traffic control and elevator-dispatch problems.
• UI-heavy prompts (design a form, design a smart home control panel) where components react to each other.

What interviewers are actually checking:

• Can you spot the n-squared coupling and name the fix?
• Can you put the coordination logic in the right place?
• Can you articulate the god-object tradeoff without being asked? Bring that up yourself. It shows you have shipped this and felt the pain.

Draw the mesh, let it look ugly, then collapse it into a star. That one move sells the whole pattern.

Next, look at the Observer pattern (its close cousin) and the Facade pattern (also a "single front door," but for a subsystem rather than peer coordination). The chat-application LLD problem is the best place to practice all three together.