Mediator Design Pattern in Java: Centralizing Communication Between Objects to Reduce Coupling

Description / Meta Description

Learn the Mediator Design Pattern in Java with practical examples. Understand how Mediator centralizes communication between objects, reduces dependencies, simplifies complex interactions, and powers chat applications, workflow engines, UI frameworks, air traffic control systems, and enterprise orchestration platforms.


Mediator Design Pattern in Java: Centralizing Communication Between Objects to Reduce Coupling

In the previous article, we explored the Template Method Pattern, which helps standardize workflows while allowing customization of individual steps.

Template Method answers:

How do I standardize a process while allowing variation?

Mediator answers a different question:

How do I manage communication between many objects without creating a web of dependencies?

This pattern becomes valuable when systems grow and objects begin interacting heavily with one another.

You’ll find Mediator concepts in:

  • Chat Applications
  • Air Traffic Control Systems
  • Workflow Engines
  • Enterprise Orchestration Platforms
  • UI Frameworks
  • Event Coordination Systems

The Problem: Object Communication Explosion

Imagine a team collaboration application.

Users can:

Send Messages
Create Channels
Notify Users
Share Files
Mention Users

Suppose we have:

User A
User B
User C
User D

Without a Mediator:

A ↔ B
A ↔ C
A ↔ D

B ↔ C
B ↔ D

C ↔ D

Every object communicates directly with every other object.

As more users join:

Complexity Explodes

This creates:

  • Tight Coupling
  • Difficult Maintenance
  • Hard Testing
  • Poor Scalability

Visualizing the Problem

Without Mediator:

      A
    / | \
   /  |  \
  B---C---D
   \  |  /
    \ | /
      E

Every object knows every other object.

This quickly becomes unmanageable.


What We Really Want

Instead:

      A
      │
      ▼

  Mediator

  ▲  ▲  ▲
  │  │  │

  B  C  D

Objects communicate through a central coordinator.

They no longer communicate directly.

This is Mediator Pattern.


What is Mediator Pattern?

Mediator is a Behavioral Design Pattern that:

Defines an object that encapsulates how a set of objects interact.

Instead of objects talking to each other directly:

Object → Object

they communicate through:

Object
   │
   ▼

Mediator

   │
   ▼

Other Objects

The mediator controls communication.


Real Life Analogy: Air Traffic Control

One of the classic GoF examples.

Imagine an airport.

Aircraft:

Plane A
Plane B
Plane C
Plane D

Without coordination:

Chaos

Each aircraft would need to communicate with every other aircraft.

Instead:

Aircraft
     │
     ▼

Air Traffic Control

     │
     ▼

Other Aircraft

The tower becomes the mediator.

Pilots communicate with the tower.

Not each other.


Mediator Architecture

Client Objects

User A
User B
User C

    │
    ▼

Mediator

    │
    ▼

Coordinates Communication

All interaction flows through the mediator.


Step 1: Create Mediator Interface

public interface ChatMediator {

    void sendMessage(
            String message,
            User sender);

    void addUser(
            User user);
}

Mediator defines communication rules.


Step 2: Create User Abstract Class

public abstract class User {

    protected ChatMediator mediator;

    protected String name;

    public User(
            ChatMediator mediator,
            String name) {

        this.mediator = mediator;
        this.name = name;
    }

    public abstract void send(
            String message);

    public abstract void receive(
            String message);
}

Users know only the mediator.


Step 3: Create Concrete User

public class ChatUser
        extends User {

    public ChatUser(
            ChatMediator mediator,
            String name) {

        super(mediator, name);
    }

    @Override
    public void send(
            String message) {

        mediator.sendMessage(
            message,
            this);
    }

    @Override
    public void receive(
            String message) {

        System.out.println(
            name + " received: "
            + message);
    }
}

Notice:

User Does Not Know
Other Users

Step 4: Create Concrete Mediator

public class ChatRoomMediator
        implements ChatMediator {

    private List<User> users =
            new ArrayList<>();

    @Override
    public void addUser(
            User user) {

        users.add(user);
    }

    @Override
    public void sendMessage(
            String message,
            User sender) {

        for(User user : users) {

            if(user != sender) {

                user.receive(message);
            }
        }
    }
}

Mediator coordinates delivery.


Client Usage

ChatMediator room =
        new ChatRoomMediator();

User rahul =
        new ChatUser(room, "Rahul");

User amit =
        new ChatUser(room, "Amit");

room.addUser(rahul);
room.addUser(amit);

rahul.send("Hello Everyone");

Output:

Amit received: Hello Everyone

Communication occurs through the mediator.


Why Mediator Works

Without Mediator:

Users Know Users

Many Dependencies

With Mediator:

Users Know Mediator

Single Dependency

Complexity reduces dramatically.


Chat Application Example

Modern messaging platforms work similarly.

User
  │
  ▼

Messaging Service

  │
  ▼

Recipients

Users don’t directly communicate.

The messaging platform mediates.


Enterprise Workflow Example

Imagine an insurance claim process.

Participants:

Customer
Claims Team
Fraud Team
Finance Team
Audit Team

Without Mediator:

Everyone Talks To Everyone

With Mediator:

Workflow Engine

coordinates interactions.


UI Framework Example

Suppose a screen contains:

Text Box
Dropdown
Checkbox
Button

Selecting a value:

Enable Button
Disable Fields
Update Dropdown

Without Mediator:

Each Component
Knows Every Other Component

With Mediator:

UI Controller

coordinates updates.


Spring Integration Example

Many orchestration frameworks resemble Mediator.

Example:

Order Service
Inventory Service
Payment Service
Shipping Service

An orchestration layer coordinates interactions.

Instead of direct service-to-service communication.


Microservices Orchestration

Two common styles exist.


Choreography

Service A
  ↓
Service B
  ↓
Service C

Services communicate directly.

Often resembles Observer.


Orchestration

Workflow Engine

     │
     ▼

Service A
Service B
Service C

Workflow engine acts as Mediator.

Examples:

  • Camunda
  • Temporal
  • Netflix Conductor

Benefits of Mediator Pattern

1. Reduces Coupling

Major advantage.

Objects no longer know each other.


2. Simplifies Communication

Centralized communication logic.


3. Easier Maintenance

Changes happen in one place.


4. Better Reusability

Objects become more independent.


5. Improved Testability

Mediator can be mocked easily.


Common Mistakes

Mistake 1: God Mediator

Mediator becomes:

5000 Lines

containing all business logic.

Keep responsibilities focused.


Mistake 2: Moving Everything Into Mediator

Mediator should coordinate.

Not become the application.


Mistake 3: Using Mediator For Simple Systems

If only:

Two Objects

communicate,

Mediator may be unnecessary.


Mediator vs Observer

Common interview question.


Observer

Publisher
    ↓
Many Subscribers

Broadcast communication.


Mediator

Many Objects
      ↓
Central Coordinator

Managed communication.


Mediator vs Facade

Another common confusion.


Facade

Purpose:

Simplify Usage

of a subsystem.


Mediator

Purpose:

Coordinate Communication

between peers.


Mediator vs Chain of Responsibility

Chain

Request flows through:

Handler 1
Handler 2
Handler 3

Mediator

Objects communicate through:

Central Coordinator

Different intent.


When Should You Use Mediator?

Use Mediator when:

✔ Many objects communicate

✔ Dependencies become complex

✔ Communication rules are centralized

✔ Workflow orchestration exists

✔ UI coordination exists

Examples:

  • Chat Systems
  • Workflow Engines
  • Air Traffic Control
  • Enterprise Orchestration
  • UI Controllers
  • Collaboration Platforms

Avoid Mediator when:

❌ Very few objects interact

❌ Direct communication is simpler

❌ Mediator would become overly complex


Behavioral Patterns Covered So Far

PatternPurpose
StrategyChoose algorithms dynamically
ObserverPublish-subscribe communication
CommandEncapsulate actions
Chain of ResponsibilityProcess requests through handlers
StateChange behavior based on state
Template MethodDefine workflow skeleton
MediatorCentralize communication

Behavioral Pattern Cheat Sheet

Strategy
→ Choose Behavior

Observer
→ Broadcast Events

Command
→ Encapsulate Actions

Chain of Responsibility
→ Process Through Pipeline

State
→ Change Behavior By State

Template Method
→ Define Workflow Skeleton

Mediator
→ Coordinate Communication

Final Thoughts

The Mediator Pattern solves an important architectural challenge:

How do we manage communication among many objects without creating a tangled web of dependencies?

By introducing a central coordinator, we gain:

  • Lower Coupling
  • Better Maintainability
  • Easier Testing
  • Simpler Communication
  • Cleaner Architectures

This is why Mediator concepts appear throughout:

  • Workflow Engines
  • Chat Platforms
  • UI Frameworks
  • Enterprise Orchestration Systems
  • Air Traffic Control Systems
  • Microservice Orchestration Platforms

Whenever you find many objects communicating with many other objects, consider whether a Mediator can simplify the design.

In the next article, we’ll explore:

Iterator Design Pattern — Traversing Collections Without Exposing Internal Structure

You’ll learn how Java Collections, Streams, database cursors, paginated APIs, and enterprise data processing frameworks rely heavily on Iterator Pattern concepts.

Leave a Reply

Your email address will not be published. Required fields are marked *