DEV Community

Cover image for Design Patterns Simplified: Part 11 — Mediator Pattern (a.k.a. “Talk to the Middleman!”)
Prateek Prabhakar
Prateek Prabhakar

Posted on • Edited on • Originally published at Medium

Design Patterns Simplified: Part 11 — Mediator Pattern (a.k.a. “Talk to the Middleman!”)

#designpatterns #softwareengineering #cleancode #techinterview

The Mediator Pattern belongs to the Behavioral category of design patterns.

Why? Because it’s all about organizing communication between objects in a way that reduces dependencies and promotes clean coordination.

The Core Idea:
Imagine you have a bunch of colleagues working on a project. If everyone starts emailing each other directly regarding their tasks, things will get messy. There will be confusion, overlapping responsibilities, and missed deadlines.

So, what do you do?
You bring in a Project Manager (a.k.a. The Mediator).

Now, instead of talking to each other directly, everyone communicates through the manager. The manager controls the flow, delegates tasks, and keeps everything in sync.

That’s exactly what the Mediator Pattern does in code.

Another Example: Air Traffic Control

Think of airplanes landing and taking off. Planes don’t communicate with each other directly. It is a no brainer, as that would be chaotic. Instead, they all speak to one person - the Air Traffic Controller.

Plane A: “Can I land?”
ATC: “Hold. Plane B is taking off.”
Plane B: “Ready for takeoff.”
ATC: “Cleared for takeoff.”

All coordination is handled centrally. This is the Mediator Pattern in action.

What is the Mediator Pattern?

The Mediator Pattern defines an object (the mediator) that encapsulates how a set of objects interact. Instead of referring to each other directly, objects communicate via the mediator, reducing tight coupling and improving maintainability.

It allows you to,

  • Centralize complex communication logic
  • Reduce dependencies between components
  • Keep each component focused on its own responsibility

The Chat Room

Let’s say you are building a group chat feature.

Without a mediator,
Every user knows about every other user.
Each one has to send messages to all others.
A new user means there would be updates everywhere.

With a ChatRoom (Mediator),
Each user sends the message to the chat room.
The chat room handles broadcasting it to others.
No user needs to know who else exists (in terms of responsibility to send messages directly).

What does the code look like? 

// Step 1: Define Mediator Interface
Interface ChatRoom
    ShowMessage(sender, message)

// Step 2: Concrete Mediator
Class SimpleChatRoom implements ChatRoom
    Method ShowMessage(sender, message)
        Print("[" + sender.Name + "]: " + message)

// Step 3: Define Colleague(User)
Class User
    Property Name
    Property ChatRoom

    Constructor(name, chatRoom)
        this.Name = name
        this.ChatRoom = chatRoom

    Method Send(message)
        ChatRoom.ShowMessage(this, message)

// caller logic
room = new SimpleChatRoom()

alice = new User("Alice", room)
bob = new User("Bob", room)

alice.Send("Hi Bob!")
bob.Send("Hey Alice!")
Enter fullscreen mode Exit fullscreen mode

In the above example, User objects do not talk to each other directly. They send messages through the ChatRoom (Mediator).It is the ChatRoom that handles coordination and display. This reduces coupling i.e. users don’t need to know about other users, but just the mediator.

NOTE: If you noticed the term "Colleague" in the code example and wondered what it means? In the Mediator Pattern, a Colleague is any object that participates in communication but interacts only through the Mediator, never directly with other objects.

What Did We Achieve?

  • Users don’t talk to each other directly
  • They rely on the Mediator (ChatRoom) for coordination
  • Loose coupling = better maintainability
  • Scalability = easily add new users without extra changes

When Should You Use the Mediator Pattern?

  • When multiple components interact in complex ways
  • When tight coupling between classes becomes unmanageable
  • When you want to centralize communication and coordination

Use Cases?

  • Chat systems or notification hubs
  • UI component interactions (e.g., button clicks triggering updates)
  • Airplane or vehicle coordination systems
  • Messaging/event systems
  • Centralized command dispatchers

To summarize, it would be apt to say,

Mediator Pattern is like a middleman who knows everyone, coordinates all communication, and keeps things smooth and organized.

It helps break the web of direct dependencies and delegates coordination to a single, central object — the Mediator.

So, the next time your code starts turning into a tangled mess of “who-talks-to-whom,” just call Mediator Pattern to the rescue!

Next up in the series: Memento Pattern. Dive right in!

BONUS: Mediator vs Observer — Aren’t They Similar?

If you have come across the Observer Pattern before, you might be thinking, “Isn’t that kind of like Mediator?”

They do look alike on the surface as both deal with communication between objects but they solve very different problems.
Here is a quick comparison between the two,

Comparison between Mediator and Observer Pattern

To summarize the difference,
Use the Mediator Pattern when you want to centralize and control complex object interactions.
Use the Observer Pattern when you want to broadcast updates to many listeners without tight coupling.

Top comments (0)