Mediator Design Pattern

The Mediator Design Pattern is a behavioral design pattern that encapsulates how a set of objects interact.

Instead of letting objects communicate directly with each other, the pattern introduces a mediator object that coordinates all interactions.

This helps us:

• reduce chaotic dependencies
• avoid tight coupling
• centralize communication rules
• simplify object relationships
• make systems easier to maintain

Introduction: From Chaos to Coordination

Imagine a busy intersection with no traffic lights.

Every car tries to move independently.
Every driver makes their own decision.
The result is chaos.

Now imagine a traffic controller standing in the middle and telling each car when to move.

That is the Mediator pattern.

It replaces a tangled web of direct connections with a central coordinator.

The Problem: A Web of Tangled Connections

When objects communicate directly with each other, the number of relationships grows very fast.

If one object must talk to many others, it needs references to all of them.

If there are n objects, then each object may need up to n - 1 references.

This creates a complicated, brittle design.

Why direct communication becomes a problem

Direct communication diagram

As more objects are added, the network becomes messy.

Core Idea of Mediator

The Mediator pattern introduces a central object called the Mediator.

All other objects become Colleagues.

They no longer talk to each other directly. They talk to the mediator, and the mediator decides how to route or coordinate the interaction.

Formal definition

The Mediator pattern defines an object that encapsulates how a set of objects interact.

It promotes loose coupling by preventing objects from referring to each other directly, and lets them communicate through the mediator instead.

Main participants

UML structure

Why Mediator is useful

The mediator centralizes communication logic.

Instead of each object knowing about every other object, each object only knows:

• the mediator
• how to send a request to the mediator
• how to receive a response from the mediator

This dramatically reduces complexity.

Real-world analogy: Chat Room

A chat application is one of the best examples of the Mediator pattern.

Suppose there are many users in a chat room.

Without a mediator:

• every user must know every other user
• private messaging becomes messy
• mute logic becomes scattered
• group communication becomes hard to manage

With a mediator:

• each user sends messages to the chat room
• the chat room decides where to deliver them
• mute rules, broadcast rules, and routing rules stay in one place

Chat room flow

How Mediator simplifies the system

The object relationships become:

• many colleagues know one mediator
• mediator knows all colleagues
• colleagues do not know each other directly

That means:

• less coupling
• easier changes
• simpler object classes

Direct communication vs Mediator communication

Why this improves design

If a new colleague joins the system:

• direct communication requires changes in many classes
• mediator communication usually requires only registration with the mediator

If a new communication rule is added:

• direct communication spreads the logic everywhere
• mediator communication updates one central place

Chat Room Example

A chat room mediator can manage:

• user registration
• public broadcasts
• private messages
• mute lists
• join/leave notifications

Without Mediator

If users talk directly:

• each user needs references to every other user
• mute logic is duplicated
• message routing is scattered

This creates a tangled system.

With Mediator

If users communicate through a mediator:

• users send message requests to mediator
• mediator decides delivery
• message rules are centralized

This is far cleaner.

Example communication flow

Why mediator is not just a broadcaster

Mediator is not only for broadcasting messages.

It can also:

• enforce rules
• coordinate workflows
• validate actions
• resolve conflicts
• route commands based on context

That makes it much broader than a simple notifier.

Mediator and loose coupling

One of the biggest advantages of Mediator is loose coupling.

Example features managed centrally

In a chat room, mediator may manage:

• who is online
• who muted whom
• who should receive a message
• whether a message is public or private

The user objects remain simple.

Mediator Pattern structure

The mediator usually has:

• a method for registering colleagues
• a method for receiving requests from colleagues
• logic for routing or coordinating communication

The colleague usually has:

• a reference to the mediator
• a method to send messages
• a method to receive messages

The role of colleagues

Colleagues should not depend on each other directly.

Instead:

• a colleague sends data or requests to the mediator
• the mediator handles the interaction

This is what keeps the code clean.

Example: Chat mediator in action

Suppose:

• Alice sends a message
• Bob is muted
• Charlie is not muted

The mediator:

• receives Alice’s message
• checks delivery rules
• sends it to Charlie
• skips Bob

The logic stays in one place.

Stateful coordination

Mediator is especially useful when interactions are stateful.

Examples:

• form field validation
• UI button enable/disable rules
• chat applications
• multiplayer games
• workflow engines

Real-world examples

Example: GUI form

A login form may have:

• username field
• password field
• login button
• remember me checkbox

Without mediator:

• every field directly knows about every other field

With mediator:

• the form controller coordinates state changes

For example:

• login button becomes enabled only when username and password are valid

GUI mediator diagram

Mediator vs Observer

These two patterns are often confused.

They may both involve a central object and multiple participants.

But their intent is different.

Simple distinction

Observer

One object changes, and many observers are notified.

Mediator

Many objects interact through a central coordinator.

Mediator vs Observer diagram

Mediator vs Facade

These patterns also look similar, but their goals differ.

Why Mediator improves SRP

Without mediator:

• objects handle their own behavior
• plus they manage communication with others
• plus they manage cross-object rules

That is too much responsibility.

With mediator:

• communication logic is moved out
• each colleague becomes focused
• mediator handles interaction rules

This is a strong SRP improvement.

Benefits of Mediator Pattern

Drawbacks of Mediator Pattern

Common mistakes

When to use Mediator Pattern

Use it when:

• many objects interact in complex ways
• direct communication creates tangled dependencies
• you want to centralize coordination
• UI components need to coordinate
• chat or workflow rules should be managed in one place

When not to use Mediator Pattern

Avoid it when:

• there are only a few objects
• communication is simple
• the mediator would become too large
• direct communication is already clean and manageable

Example: Chat Room

#include <iostream>
#include <vector>
#include <string>
using namespace std;
 
class Mediator {
public:
    virtual void sendMessage(const string& message, const string& sender) = 0;
    virtual void registerUser(class User* user) = 0;
    virtual ~Mediator() = default;
};
 
class User {
protected:
    Mediator* mediator;
    string name;
 
public:
    User(const string& name, Mediator* mediator) : name(name), mediator(mediator) {}
 
    virtual void send(const string& message) = 0;
    virtual void receive(const string& message) = 0;
    string getName() const { return name; }
};
 
class ChatMediator : public Mediator {
private:
    vector<User*> users;
 
public:
    void registerUser(User* user) override {
        users.push_back(user);
    }
 
    void sendMessage(const string& message, const string& sender) override {
        for (User* user : users) {
            if (user->getName() != sender) {
                user->receive(sender + ": " + message);
            }
        }
    }
};
 
class ChatUser : public User {
public:
    ChatUser(const string& name, Mediator* mediator) : User(name, mediator) {}
 
    void send(const string& message) override {
        mediator->sendMessage(message, name);
    }
 
    void receive(const string& message) override {
        cout << name << " received: " << message << endl;
    }
};
 
int main() {
    ChatMediator mediator;
 
    ChatUser alice("Alice", &mediator);
    ChatUser bob("Bob", &mediator);
    ChatUser charlie("Charlie", &mediator);
 
    mediator.registerUser(&alice);
    mediator.registerUser(&bob);
    mediator.registerUser(&charlie);
 
    alice.send("Hello everyone");
    bob.send("Hi Alice");
 
    return 0;
}

import java.util.ArrayList;
import java.util.List;
 
interface Mediator {
    void sendMessage(String message, String sender);
    void registerUser(User user);
}
 
abstract class User {
    protected Mediator mediator;
    protected String name;
 
    public User(String name, Mediator mediator) {
        this.name = name;
        this.mediator = mediator;
    }
 
    public String getName() {
        return name;
    }
 
    public abstract void send(String message);
    public abstract void receive(String message);
}
 
class ChatMediator implements Mediator {
    private List<User> users = new ArrayList<>();
 
    public void registerUser(User user) {
        users.add(user);
    }
 
    public void sendMessage(String message, String sender) {
        for (User user : users) {
            if (!user.getName().equals(sender)) {
                user.receive(sender + ": " + message);
            }
        }
    }
}
 
class ChatUser extends User {
    public ChatUser(String name, Mediator mediator) {
        super(name, mediator);
    }
 
    public void send(String message) {
        mediator.sendMessage(message, name);
    }
 
    public void receive(String message) {
        System.out.println(name + " received: " + message);
    }
}
 
public class Main {
    public static void main(String[] args) {
        ChatMediator mediator = new ChatMediator();
 
        ChatUser alice = new ChatUser("Alice", mediator);
        ChatUser bob = new ChatUser("Bob", mediator);
        ChatUser charlie = new ChatUser("Charlie", mediator);
 
        mediator.registerUser(alice);
        mediator.registerUser(bob);
        mediator.registerUser(charlie);
 
        alice.send("Hello everyone");
        bob.send("Hi Alice");
    }
}

from abc import ABC, abstractmethod
 
class Mediator(ABC):
    @abstractmethod
    def send_message(self, message, sender):
        pass
 
    @abstractmethod
    def register_user(self, user):
        pass
 
class User(ABC):
    def __init__(self, name, mediator):
        self.name = name
        self.mediator = mediator
 
    @abstractmethod
    def send(self, message):
        pass
 
    @abstractmethod
    def receive(self, message):
        pass
 
class ChatMediator(Mediator):
    def __init__(self):
        self.users = []
 
    def register_user(self, user):
        self.users.append(user)
 
    def send_message(self, message, sender):
        for user in self.users:
            if user.name != sender:
                user.receive(f"{sender}: {message}")
 
class ChatUser(User):
    def send(self, message):
        self.mediator.send_message(message, self.name)
 
    def receive(self, message):
        print(f"{self.name} received: {message}")
 
mediator = ChatMediator()
 
alice = ChatUser("Alice", mediator)
bob = ChatUser("Bob", mediator)
charlie = ChatUser("Charlie", mediator)
 
mediator.register_user(alice)
mediator.register_user(bob)
mediator.register_user(charlie)
 
alice.send("Hello everyone")
bob.send("Hi Alice")

C++ explanation

• Mediator defines the communication contract
• ChatMediator controls message routing
• User is the colleague abstraction
• ChatUser sends and receives through mediator
• users do not communicate directly

Java explanation

• the mediator stores the user list
• each user sends messages through the mediator
• message delivery stays centralized
• the colleague classes remain simple

Python explanation

• ChatMediator coordinates the room
• users only know the mediator
• users are decoupled from each other
• the logic is centralized and easy to manage

Sequence Diagram: Chat Room Message Flow

Another real-world example: Air traffic control

An air traffic controller coordinates:

• takeoff
• landing
• runway allocation
• communication between planes

Planes do not coordinate directly with each other. They use the controller.

That is the Mediator pattern.

Air traffic control diagram

Another real-world example: UI form controller

A form mediator can:

• enable or disable buttons
• validate fields
• trigger actions based on input
• coordinate related widgets

This is common in GUI systems.

Benefits of Mediator

Drawbacks of Mediator

Common mistakes

Mediator vs Observer

Mediator vs Facade

Mediator and SOLID

Summary

The Mediator Pattern centralizes complex communication between objects.

It:

• reduces direct dependencies
• keeps objects from knowing too much about each other
• moves interaction logic into one place
• improves maintainability and flexibility

It is especially useful for:

• chat systems
• UI coordination
• workflow systems
• matchmaking systems
• control systems

Final takeaway

The Mediator Pattern is about this simple idea:

Do not let every object talk to every other object directly. Put a mediator in the middle and let it coordinate the interaction.

That gives you:

• less chaos
• less coupling
• cleaner code
• easier maintenance

It is one of the best patterns for systems with many interacting objects.