What is the Mediator design pattern, and what problem does it solve in object-oriented Java code?
answer
- Star, not web: colleagues talk through one hub
- Behavioral GoF pattern; n-to-n becomes n-to-1
- Colleagues + Mediator roles
- Centralizes interaction logic
- Risk = god object
basics
~20 sMediator is a behavioral pattern where objects don't talk to each other directly. Instead, they talk through a central object called the mediator. This reduces tangled connections, so each object only knows the mediator, not all the others.
solid answer
~40 sMediator is a behavioral design pattern that centralizes how a set of objects (called colleagues) communicate. Instead of each colleague holding references to and calling every other colleague directly (many-to-many coupling that grows roughly n-squared), every colleague holds a single reference to a mediator. When something happens, the colleague notifies the mediator, and the mediator decides which other colleagues to update. This converts a dense web of direct dependencies into a star shape centered on the mediator. The benefit is looser coupling and easier reuse: a colleague can be reused with a different mediator, and interaction logic lives in one place. A classic example is a dialog box coordinating its buttons, text fields, and checkboxes. The main risk is that the mediator can become a god object that absorbs too much logic.
go deeper
Can state that colleagues talk through a central mediator instead of each other, and name the benefit (less tangled coupling). Recognizes the star-vs-web picture.
Explains the Colleague/Mediator roles, the n-to-n vs n-to-1 coupling argument, and gives a concrete example (dialog coordinating widgets). Knows it is behavioral.
Articulates the god-object risk and mitigations, contrasts Mediator with Observer and Facade, and discusses when the indirection is and isn't worth it.
Frames Mediator at the architecture level (e.g. when a coordinating component is justified vs. event bus / pub-sub), weighs testability and team boundaries, and sets guidelines for keeping mediators cohesive.
## What the Mediator pattern is The **Mediator pattern** is one of the original Gang of Four (GoF) **behavioral** design patterns. "Behavioral" means it is about *how objects communicate and distribute responsibility*, not about how they are created or structured. First, some vocabulary used throughout: - **Object / instance**: a runtime thing in your program (e.g. a specific button on screen). - **Reference**: a variable that points to another object, letting you call its methods. If object A has a reference to object B, A *depends on* B. - **Coupling**: how much one part of a program needs to know about another. *Tight (high) coupling* means lots of direct references; *loose coupling* means few. Loose coupling is generally desirable because it makes code easier to change, test, and reuse. - **Colleagues**: the GoF name for the objects whose interactions the mediator coordinates. - **Mediator**: the central object every colleague talks to instead of talking to each other. ## The problem it solves Imagine a login form with: a username field, a password field, a "Login" button, and a "remember me" checkbox. The rules: the Login button should be disabled until both fields are non-empty; checking "remember me" reveals an extra field; and so on. If each widget talks **directly** to the others, every widget needs references to every widget it influences. With *n* objects you can end up with up to *n × (n − 1)* directed connections — the dependency graph becomes a dense web. Adding a new widget means touching many existing classes, and no single widget can be understood or reused in isolation because it is wired to all the others. ## The Mediator solution Insert one object in the middle. Every colleague gets a single reference: to the **mediator**. When a colleague's state changes, it does **not** call other colleagues — it calls the mediator ("I changed"). The mediator contains the interaction rules and calls back the colleagues that need updating. The dense web collapses into a **star**: many colleagues, one hub. Result: - Each colleague depends only on the mediator (plus the small interface it exposes), not on its peers. - All the "who-reacts-to-what" logic lives in **one** place — easy to find and change. - A colleague class becomes reusable: drop it into a different screen with a different mediator and different rules. ## Structure (roles) 1. **Mediator** (often an interface): declares the method colleagues call to signal events, e.g. `notify(sender, event)`. 2. **ConcreteMediator**: implements the coordination logic and holds references to the colleagues it manages. 3. **Colleague**: each participating object; it holds a reference to the mediator and calls it instead of calling peers. ## Java flavor In Java the mediator is normally a class (or interface + class). Colleagues are passed (or look up) the mediator. The pattern shows up naturally in **GUI toolkits like Swing**, where a controller/dialog coordinates its child components, and conceptually in things like a chat-room server routing messages between participants. ## Trade-offs - **Pro**: turns n-to-n coupling into n-to-1; centralizes and clarifies interaction logic; improves reuse and testability of colleagues. - **Con — the god object**: because the mediator collects all interaction logic, it can grow huge and become hard to maintain — the very complexity you removed from the colleagues reappears, concentrated in one class. Mitigate by keeping mediators focused (one per cohesive cluster) and splitting when they grow. ## How it differs from neighbors - **Observer** also decouples senders from receivers, but it is a one-to-many *broadcast* with no central decision-maker; Mediator centralizes *bidirectional* coordination logic and decides who reacts. - **Facade** simplifies access to a subsystem from the *outside* (one-directional, the subsystem doesn't know the facade); Mediator coordinates peers that *do* know it, with two-way traffic.
- Doesn't centralizing everything just move the complexity into the mediator?Yes, that's the core trade-off. You trade many tangled dependencies for one place that holds the interaction logic. That place is easier to find and change, but it can grow into a god object, so you keep each mediator scoped to one cohesive cluster and split it when it gets large.
- How is Mediator different from Observer?Observer is a one-to-many broadcast: a subject notifies subscribers that don't know each other, with no central coordinator deciding behavior. Mediator centralizes two-way coordination logic and actively decides which colleagues to update in response to an event.
An air-traffic control tower: planes (colleagues) never coordinate landings by radioing each other directly; they all talk to the tower (mediator), which decides who lands when. Remove the tower and every plane would need to track every other plane.
saying these in an interview costs you the question
- Saying Mediator is a creational or structural pattern (it is behavioral).
- Confusing it with Facade — Facade hides a subsystem from outside callers and is one-directional; Mediator coordinates peers that know it, two-way.
- Claiming it removes complexity rather than relocating/centralizing it.
- Thinking colleagues still reference each other 'a little' — the point is they reference only the mediator.