What is the Mediator Pattern?
Learn the Mediator design pattern — centralizing colleague communication, avoiding a tangled mesh — with a Java example and interview Q&A.
Expected Interview Answer
The Mediator pattern centralizes communication between a set of objects into a single mediator object, so those objects (colleagues) interact only through the mediator instead of holding direct references to one another.
Without a mediator, a group of interacting objects tends to form a dense mesh of direct references, where every object must know about every other object it communicates with, making the system hard to change. The Mediator pattern breaks that mesh into a star topology: each colleague holds a reference only to the mediator, and notifies it of events (e.g. notify(sender, event)); the mediator then decides how to route that event to the other colleagues. This keeps individual colleague classes simple and reusable, while the coordination logic — often the most complex and most likely to change — lives in one place. The tradeoff is that the mediator itself can grow into a large, complex 'god object' if too much logic accumulates there, so its responsibilities should stay focused on coordination, not business logic.
- Reduces many-to-many object coupling to a single point of coordination
- Lets colleague classes stay simple and independently reusable
- Centralizes interaction logic, making it easier to change coordination rules
- Makes it easier to add new colleagues without rewiring every existing one
AI Mentor Explanation
On the field, fielders don’t shout instructions directly to every other fielder; they relay through the captain, who decides how to reposition the field based on what one fielder reports. Each fielder only needs a channel to the captain (the mediator), not to all ten teammates individually, which keeps each fielder’s role simple. If a new fielder joins mid-innings, they just need to know how to communicate with the captain, not renegotiate a direct line with everyone else — exactly how colleagues in the Mediator pattern only depend on the mediator.
Step-by-Step Explanation
Step 1
Identify the tangled interactions
Spot a group of objects communicating directly with many others, forming a dense mesh.
Step 2
Define a Mediator interface
Declare a method like notify(sender, event) that colleagues call to report changes.
Step 3
Give each colleague a mediator reference
Colleagues hold only a reference to the mediator, not to each other.
Step 4
Centralize routing logic
The concrete mediator decides, based on the event, which other colleagues to notify or update.
What Interviewer Expects
- A clear definition: centralizing many-to-many interactions into one coordinator
- Understanding of the mesh-to-star topology change it produces
- A concrete example (chat room, UI dialog, air traffic control)
- Awareness of the risk that the mediator can become a bloated 'god object'
Common Mistakes
- Confusing Mediator with Observer (Mediator centralizes coordination logic; Observer just broadcasts notifications)
- Letting business logic accumulate inside the mediator instead of in the colleagues
- Giving colleagues direct references to each other anyway, defeating the pattern’s purpose
- Assuming Mediator eliminates coupling entirely rather than centralizing it in one place
Best Answer (HR Friendly)
“The Mediator pattern puts a single coordinator object between a group of objects that would otherwise all need to know about each other. Instead of a tangled web of direct connections, each object only talks to the mediator, and the mediator decides how that update should ripple out to everyone else. It’s the same idea as a project manager coordinating between teams instead of every team negotiating directly with every other team.”
Code Example
import java.util.ArrayList;
import java.util.List;
interface ChatMediator {
void sendMessage(String message, User sender);
void addUser(User user);
}
class ChatRoom implements ChatMediator {
private final List<User> users = new ArrayList<>();
public void addUser(User user) { users.add(user); }
public void sendMessage(String message, User sender) {
for (User u : users) {
if (u != sender) u.receive(message);
}
}
}
class User {
private final String name;
private final ChatMediator mediator;
User(String name, ChatMediator mediator) {
this.name = name;
this.mediator = mediator;
mediator.addUser(this);
}
void send(String message) { mediator.sendMessage(name + ": " + message, this); }
void receive(String message) { System.out.println(name + " received: " + message); }
}
ChatRoom room = new ChatRoom();
User alice = new User("Alice", room);
User bob = new User("Bob", room);
alice.send("Hi Bob!"); // Bob receives "Alice: Hi Bob!"Follow-up Questions
- How does the Mediator pattern differ from the Observer pattern?
- What is the risk of the mediator becoming a god object, and how do you avoid it?
- Where does Mediator show up in GUI frameworks or dialog boxes?
- How would you test colleague classes in isolation from the mediator?
MCQ Practice
1. What problem does the Mediator pattern primarily solve?
Mediator replaces a mesh of direct references between colleagues with a single coordinating object each colleague talks to.
2. In the Mediator pattern, how do colleague objects communicate?
Colleagues hold a reference only to the mediator and notify it of events; the mediator routes interactions between colleagues.
3. What is a common risk of overusing the Mediator pattern?
If too much coordination and business logic accumulates in one mediator, it can become a hard-to-maintain god object.
Flash Cards
Mediator pattern in one line? — A central object coordinates interactions between colleagues so they never reference each other directly.
Topology change it produces? — From a many-to-many mesh of direct references to a star topology through one mediator.
Key risk? — The mediator can grow into a bloated god object if too much logic accumulates there.
Classic real-world example? — Air traffic control coordinating planes that never communicate directly with each other.