Introduction
Imagine you are building a chat application.
The application contains multiple users:
Rahul
Priya
Aman
Neha
If every user directly communicates with every other user, the relationships quickly become complex.
Rahul ↔ Priya
Rahul ↔ Aman
Rahul ↔ Neha
Priya ↔ Aman
Priya ↔ Neha
Aman ↔ Neha
As more users join, the number of connections grows rapidly.
Managing such communication becomes difficult.
This is where the Mediator Design Pattern helps.
Instead of objects communicating directly with each other, they communicate through a central mediator.
What is the Mediator Pattern?
The Mediator Pattern is a behavioral design pattern that defines an object that encapsulates how a set of objects interact.
In simple words:
The Mediator Pattern centralizes communication between multiple objects.
Instead of objects directly talking to each other, they communicate through a mediator.
This reduces dependencies and makes the system easier to maintain.
Real World Analogy
Think about an airport control tower.
Pilots do not directly communicate with every other airplane.
Instead:
Plane A
│
▼
Control Tower
▲
│
Plane B
Whenever a plane wants to communicate:
It sends a message to the control tower.
The control tower coordinates communication.
This prevents chaos and reduces complexity.
The control tower acts as a Mediator.
Why Do We Need the Mediator Pattern?
Suppose we are building a smart home system.
Devices include:
Air Conditioner
Heater
Fan
Temperature Sensor
Without a mediator:
Air Conditioner ↔ Heater
Air Conditioner ↔ Fan
Fan ↔ Heater
Temperature Sensor ↔ All Devices
Every device becomes aware of every other device.
As new devices are added:
Smart Lights
Humidifier
Air Purifier
The dependencies increase dramatically.
Problems Without Mediator Pattern
1. Tight Coupling
Objects directly depend on one another.
Object A → Object B
Object A → Object C
Object A → Object D
2. Difficult Maintenance
Changes in one object may affect multiple others.
3. Complex Communication Logic
Communication becomes scattered across many classes.
4. Poor Scalability
Adding new objects increases dependencies.
Solution: Mediator Pattern
The Mediator Pattern introduces a central object that manages communication.
Instead of:
Object A ↔ Object B
Object A ↔ Object C
Object B ↔ Object C
We do:
Object A
│
▼
Mediator
▲
│
Object B
Object C
Now objects communicate only with the mediator.
Key Components of the Mediator Pattern
The Mediator Pattern typically consists of:
1. Mediator Interface
Defines communication methods.
2. Concrete Mediator
Implements communication logic.
3. Colleague Interface
Represents participating objects.
4. Concrete Colleagues
Actual objects communicating through the mediator.
Structure of Mediator Pattern
Mediator
▲
│
---------------------
│ │ │
User A User B User C
All communication passes through the mediator.
Example: Chat Room System
Let's build a simple chat room application.
Step 1: Create Mediator Interface
Step 2: Create User Class
Step 3: Create Concrete Mediator
Step 4: Create a Concrete User
Step 5: Client Code
Output
Rahul sends: Hello Everyone!
Priya receives: Hello Everyone!
Aman receives: Hello Everyone!
How the Mediator Pattern Works
Let's understand the complete flow.
Step 1
A user sends a message.
rahul->send("Hello Everyone!");
Step 2
The user forwards the message to the mediator.
mediator->sendMessage(...)
Step 3
The mediator decides who should receive it.
Step 4
The mediator forwards the message.
user->receive(...)
Notice that users never communicate directly.
Key Idea Behind the Pattern
The most important idea is:
Objects should communicate through a mediator instead of directly with each other.
This reduces the number of dependencies.
Without mediator:
n objects
Connections = n(n-1)/2
With mediator:
n objects
Connections = n
This dramatically simplifies communication.
Mediator vs Observer Pattern
A common interview question.
| Mediator Pattern | Observer Pattern |
|---|---|
| Centralizes communication | Handles notifications |
| Many-to-many communication | One-to-many communication |
| Objects communicate through a mediator | Subject notifies observers |
| Focuses on interaction | Focuses on event propagation |
Example Difference
Observer:
YouTube Channel
│
▼
Subscribers
Mediator:
User A
User B
User C
│
▼
Chat Room
Mediator vs Facade Pattern
Another common interview question.
| Mediator | Facade |
|---|---|
| Manages communication | Simplifies interface |
| Controls object interactions | Provides unified access |
| Objects know the mediator | Subsystems don't know the facade |
| Behavioral Pattern | Structural Pattern |
Advantages of the Mediator Pattern
1. Reduces Coupling
Objects no longer depend on one another directly.
2. Easier Maintenance
Communication logic exists in one place.
3. Better Scalability
Adding new colleagues becomes easier.
4. Improved Reusability
Colleagues can be reused independently.
5. Centralized Communication
Interaction rules are easier to manage.
Disadvantages of the Mediator Pattern
1. Mediator Can Become Large
As communication rules grow:
Mediator
├── Rule A
├── Rule B
├── Rule C
└── Rule D
The mediator can become complex.
2. Single Point of Complexity
Too much logic may accumulate in the mediator.
3. Harder to Understand Initially
Beginners may find the additional layer confusing.
Real World Applications
The Mediator Pattern is widely used in:
Chat applications
Air traffic control systems
Smart home systems
GUI frameworks
Event management systems
Multiplayer games
Workflow engines
Messaging systems
Collaboration platforms
Many UI frameworks internally use Mediator-like architectures.
Common Beginner Mistakes
1. Putting Business Logic Inside Colleagues
Communication logic should remain inside the mediator.
2. Allowing Direct Communication
Avoid:
userA->sendTo(userB);
This defeats the purpose of the pattern.
3. Creating a God Mediator
A mediator should manage communication, not all application logic.
4. Using Mediator for Simple Systems
If only two objects communicate, the pattern may be unnecessary.
Simple Visualization
Without Mediator:
User A ↔ User B
User A ↔ User C
User B ↔ User C
Many direct dependencies.
With Mediator:
User A
│
User B
│
User C
│
▼
Mediator
All communication flows through one central component.
Summary
The Mediator Design Pattern centralizes communication between multiple objects by introducing a mediator that coordinates their interactions.
Instead of objects directly depending on one another, they communicate through the mediator, resulting in reduced coupling, better maintainability, and improved scalability. This pattern is particularly useful in systems where many objects need to interact with each other in complex ways.
Whenever object-to-object communication starts becoming difficult to manage, the Mediator Pattern provides a clean and organized solution by moving interaction logic into a dedicated mediator component.