Compare Mediator with Observer and Facade in Java. When would you pick each?
answer
- Mediator = bidirectional, central decision logic, peers know the hub
- Observer = one-to-many broadcast, no central decision-maker
- Facade = one-way simple front door; subsystem doesn't know it
- Facade is structural; the other two are behavioral
- They compose (Swing: Observer delivers, Mediator coordinates)
basics
~20 sMediator centralizes two-way coordination between peers that all know the mediator. Observer is one-way broadcast: a subject notifies subscribers that don't know each other. Facade is a simple front door to a subsystem; the subsystem doesn't know the facade. Pick by direction and who knows whom.
solid answer
~60 sAll three reduce coupling but differently. Mediator coordinates a set of peer objects (colleagues) that each hold a reference to the mediator; traffic is bidirectional and the mediator contains decision logic about who reacts to what — use it when many objects interact in complex ways and you want that logic in one place. Observer is a publish/subscribe broadcast: a subject notifies a list of observers when its state changes; observers register and unregister, the subject doesn't care who they are, and there's no central decision logic — use it for one-to-many change notification where reactions are independent. Facade provides a single simplified entry point over a complicated subsystem for outside clients; it's structural, one-directional, and the subsystem classes don't even know the facade exists — use it to hide complexity behind a clean API. The quick discriminators: Mediator = centralized bidirectional coordination among peers; Observer = decentralized one-to-many notification; Facade = simplified one-way access to a subsystem. They also compose: Swing uses Observer (listeners) to deliver events into a Mediator (dialog).
go deeper
Can give a one-line distinction: Mediator = central coordinator, Observer = broadcast notifications, Facade = simple front door.
Explains direction and who-knows-whom for each, and picks the right one for a simple scenario.
Uses the full discriminator set (cardinality, direction, central decision logic, category) and explains how the patterns compose, e.g. Observer feeding a Mediator in Swing.
Maps these onto architecture decisions (centralized coordination vs. event-driven broadcast vs. subsystem boundaries) and guides teams on when each is appropriate at scale.
## The three patterns and the terms they share All three are about **reducing coupling** — how much objects must know about each other — but they target different shapes of communication. Definitions used below: - **Coupling / decoupling**: dependencies between objects; decoupling reduces them. - **Bidirectional vs one-directional**: whether communication flows both ways or only one way. - **"Knows about"**: holds a reference to / depends on. ## Mediator - **What**: a behavioral pattern; a central **mediator** coordinates a group of **colleagues** that each hold a reference to it. Colleagues report events to the mediator; the mediator decides which colleagues to update. - **Direction**: bidirectional — colleagues call the mediator, the mediator calls colleagues back. - **Who knows whom**: colleagues know the mediator; the mediator knows the colleagues; colleagues do **not** know each other. - **Has decision logic?** Yes — the mediator centralizes the interaction rules. - **Use when**: several objects interact in complex, interdependent ways (e.g. form widgets, chat participants) and you want that web of logic collapsed into one coordinating object. ## Observer - **What**: a behavioral pattern for one-to-many change notification. A **subject** keeps a list of **observers** and notifies them when it changes. - **Direction**: essentially one-directional broadcast (subject → observers). Observers usually just react; they don't coordinate each other. - **Who knows whom**: observers register with the subject; the subject holds them only as an abstract list and does **not** know their concrete types; observers don't know each other. - **Has decision logic?** No central decision-maker — each observer independently reacts. There's no object orchestrating "who should respond." - **Use when**: many independent parties need to learn that something changed (event listeners, model→view updates, `Flow.Publisher`/`Subscriber`). ## Facade - **What**: a *structural* pattern; a single class offering a **simplified, high-level interface** over a complicated subsystem of many classes. - **Direction**: one-directional — clients call the facade, the facade calls the subsystem. - **Who knows whom**: clients know the facade; the facade knows the subsystem; crucially the subsystem classes do **not** know the facade and keep working without it. - **Has decision logic?** Minimal — it mostly *delegates*; it simplifies access rather than coordinating peers. - **Use when**: you want to hide a complex API behind an easy entry point (e.g. a high-level client wrapping many low-level calls). ## Side-by-side | Aspect | Mediator | Observer | Facade | |---|---|---|---| | GoF category | Behavioral | Behavioral | Structural | | Cardinality | Many peers ↔ one hub | One subject → many observers | Many clients → one front door | | Direction | Bidirectional | One-way broadcast | One-way (into subsystem) | | Central decision logic | Yes | No | No (delegates) | | Do the 'inner' objects know the coordinator? | Colleagues know the mediator | Observers know the subject; subject keeps them abstractly | Subsystem does NOT know the facade | | Primary intent | Coordinate complex peer interactions | Notify many of a change | Simplify access to a subsystem | ## How to pick - Need **complex, two-way coordination among peers** with the logic in one place → **Mediator**. - Need to **tell many independent listeners that something happened**, with no central orchestration → **Observer**. - Need to **hide a complicated subsystem behind a simple API** for outside callers → **Facade**. ## They compose These aren't mutually exclusive. Swing delivers UI events with **Observer** (listeners) and then routes them into a **Mediator** (the dialog) that coordinates the widgets. A **Facade** might internally use a Mediator to coordinate the subsystem it fronts. Knowing the discriminators — direction, cardinality, who-knows-whom, and whether there's central decision logic — is what lets you name the right one in an interview or design review.
- Observer and Mediator both decouple senders from receivers — what's the sharpest difference?Observer is one-to-many broadcast with no central decision logic: observers react independently and the subject doesn't orchestrate them. Mediator centralizes bidirectional coordination — the mediator actively decides which colleagues to update in response to an event. One broadcasts; the other coordinates.
- Could a Facade contain a Mediator?Yes. A Facade exposes a simple API to outside clients; internally it may use a Mediator to coordinate the subsystem objects it fronts. The patterns operate at different boundaries — Facade at the external API boundary, Mediator among the internal peers — so they compose cleanly.
saying these in an interview costs you the question
- Calling Mediator and Observer the same thing because both 'decouple' objects.
- Saying the subsystem 'talks back' to a Facade — Facade is one-way and the subsystem doesn't know it.
- Classifying Facade as behavioral (it is structural).
- Claiming Observer has a central object deciding who reacts (it does not).