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 PatternObserver Pattern
Centralizes communicationHandles notifications
Many-to-many communicationOne-to-many communication
Objects communicate through a mediatorSubject notifies observers
Focuses on interactionFocuses 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.

MediatorFacade
Manages communicationSimplifies interface
Controls object interactionsProvides unified access
Objects know the mediatorSubsystems don't know the facade
Behavioral PatternStructural 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.