How does the Mediator pattern differ from the Observer pattern, and when would you choose one over the other?
answer
- Observer = notification, Mediator = coordination
- Subject knows nobody; mediator knows everyone by role
- One-way fan-out vs bidirectional star
- Emergent behaviour vs explicit protocol
- Mediator often implemented with observers
basics
~20 sObserver broadcasts an event to subscribers the sender does not know; it carries no rules about who reacts. Mediator is a named object that knows all participants and decides what each should do. Observer is notification; Mediator is coordination.
solid answer
~50 sBoth remove direct references between collaborating objects, but they differ in *intent* and *knowledge*. Observer establishes a one-to-many notification channel: a subject publishes a state change and any number of anonymous, interchangeable observers react independently. The subject deliberately knows nothing about who listens, and no object owns the overall interaction — the resulting behaviour is emergent. Mediator establishes a coordination hub: a concrete mediator holds references to a known, usually fixed set of colleagues and encodes the rules connecting them ("when the country changes, reload states, clear postal code, recheck Submit"). The interaction protocol is explicit and readable in one class. They compose rather than compete — a mediator is frequently *implemented* with observer subscriptions so colleagues need not import it directly. Choose Observer for fan-out where reactions are independent and the publisher shouldn't care; choose Mediator when the rules *between* participants are the complicated part and must be changed as a unit.
go deeper
Say Observer is a broadcast to unknown listeners, Mediator is a coordinator that knows all participants and holds the rules.
Contrast intent, who holds knowledge, directionality, and open vs closed participant sets; note a mediator is often implemented with observers.
Drive the choice from the change pattern: if a rule change touches many classes, centralize; if reactions are independent and additive, broadcast. Name the failure modes (event spaghetti vs god object).
Generalize to system architecture — choreography (events, Observer-like) vs orchestration (a saga coordinator, Mediator-like) — and reason about ownership, debuggability, ordering guarantees, and where the bottleneck lands.
## Definitions first **Observer** (also called publish/subscribe or listener): a *subject* maintains a list of *observers*. When the subject's state changes it calls a notification method on each registered observer. The subject knows only an abstract observer interface, never concrete types, and observers may register/unregister at runtime. **Mediator**: a *mediator* object holds references to a set of *colleague* objects and contains the logic describing how they interact. Colleagues report events to the mediator (`mediator.notify(this, event)`) and the mediator decides which colleagues to act on. ## The four real differences ### 1. Intent Observer's intent is *notification* — "tell interested parties that something happened". Mediator's intent is *coordination* — "encapsulate how a set of objects interact". You can express one with the other mechanically, but the design intent you are communicating differs. ### 2. Who holds knowledge In Observer, nobody holds the whole picture. The subject knows a list of anonymous listeners; each listener knows its own reaction. The overall behaviour is emergent — to understand it you must find every subscriber. In Mediator, one concrete class knows every colleague *by role* and holds the rules. You read the protocol in one file. ### 3. Directionality and symmetry Observer is asymmetric and typically one-way: subject → observers. Observers do not normally call back into the subject as part of the protocol. Mediator is bidirectional and symmetric: colleagues call the mediator, the mediator calls colleagues, and any colleague may trigger effects on any other. ### 4. Cardinality and lifecycle Observer assumes an open, dynamic set of subscribers whose count is unknown at design time. Mediator usually coordinates a closed, known set of participants fixed at construction (the widgets of one dialog, the components of one workflow). ## They are not rivals GoF explicitly notes that a mediator can be implemented with an observer-style change-propagation mechanism: colleagues publish events, and the mediator is the (only) subscriber that applies the rules. This gives Mediator's centralized protocol *and* Observer's loose registration — colleagues need no compile-time reference to the mediator interface at all. Many UI frameworks and event-bus architectures are exactly this hybrid. The distinction blurs in an **event bus / message broker**: structurally it is Observer (publishers do not know subscribers), but if the bus also holds routing and orchestration rules it drifts into Mediator territory. What matters for a design conversation is where the *rules* live, not the wire mechanism. ## Choosing Use **Observer** when: - reactions are independent and additive (logging, metrics, cache invalidation, UI refresh); - the publisher genuinely must not care who listens; - subscribers come and go at runtime. Use **Mediator** when: - the difficult part is the *relationship* between participants, not any single reaction; - changing one rule currently requires editing several classes; - you need deterministic ordering or conditional routing ("if A then also B, unless C"); - you want one place to test the protocol. ## Failure modes of each choice - Wrong Observer choice → *event spaghetti*: reasoning about order and cycles becomes impossible because nobody owns the flow; a change cascades through handlers you cannot enumerate. - Wrong Mediator choice → *god object*: a class that grows a branch per interaction and becomes the single point everyone edits, with high merge-conflict and regression risk.
- An event bus where any component publishes and any component subscribes — is that Observer or Mediator?Structurally it is Observer: publishers do not know subscribers. It becomes Mediator-flavoured only if the bus itself holds interaction rules — routing, ordering, conditional dispatch, orchestration. If the bus is a dumb pipe and the rules live in handlers, calling it a mediator overstates what it does; the practical question is whether any single place lets you read the protocol.
- Can Observer and Mediator be used together, and what does that hybrid buy you?Yes, and it is common. Colleagues publish events without importing the mediator, and the mediator is the single subscriber that applies the coordination rules. You get Observer's zero compile-time coupling for participants plus Mediator's one readable, testable protocol — at the cost of the flow being harder to follow in a debugger, since the link from publisher to mediator is resolved at runtime.
Observer is a public-address announcement: whoever cares reacts, and the announcer never learns who did. Mediator is an air-traffic controller: it knows each aircraft by call sign and issues specific, ordered instructions to specific aircraft.