Observer vs. Mediator Design Patterns: 25-Comp-B11 Advanced Software Design, December 2018, Q16

Question 16: Observer vs. Mediator Design Patterns (Part III)

Question text not reproduced: the examination questions are © Engineers and Geoscientists BC. Open the official past paper (linked at the top of this page) to read the question, then follow the worked solution below.

Both are BEHAVIOURAL patterns (Question 14) concerned with communication between objects, but they solve different communication SHAPES.

Observer establishes a ONE-TO-MANY, publish/subscribe relationship: a single subject notifies an open-ended, dynamically-registered set of observers whenever its own state changes; the subject knows only that it has observers, never any observer's internal logic, and observers do not talk to each other at all. This is exactly the mechanism behind MVC's Model→View notification (Question 18) and Question 13's worked pattern-language example: a spreadsheet cell (subject) notifies a chart and a summary total (observers), and the chart and the summary total never communicate with one another.

Mediator centralizes MANY-TO-MANY communication among a fixed set of "colleague" objects that would otherwise need direct references to one another. Instead of every colleague knowing about every other colleague (an N² web of dependencies), each colleague talks only to a single Mediator object, which encapsulates and coordinates the interaction logic between them. A dialog box with several interdependent widgets (a checkbox that, when checked, must enable a previously-disabled text field, which in turn must revalidate a submit button) is a classic Mediator use: each widget notifies only the dialog's Mediator of its own change, and the Mediator decides which OTHER widgets must react, rather than each widget holding direct references to every other widget it might need to affect.

Key difference. Observer is a ONE-directional broadcast from a single subject to many independent observers who never interact with each other; Mediator is a hub coordinating potentially MANY colleagues, each of which may need to affect any of the others, replacing what would otherwise be a dense mesh of direct colleague-to-colleague references with one central coordinator. Put differently, Observer removes the SUBJECT's need to know its observers' concrete types; Mediator removes every COLLEAGUE's need to know every other colleague's concrete type, by concentrating the many-to-many interaction logic in one place.

Concept & Theory: One-to-Many Broadcast vs. Many-to-Many Coordination Hub

Topic: Observer decouples a single subject from many observers; Mediator decouples many colleagues from each other via one hub.

Key relations: Observer → 1 subject → N observers, no observer-to-observer link. Mediator → N colleagues ↔ 1 mediator ↔ N colleagues, no direct colleague-to-colleague link.

Why this works: Counting how many participants must be aware of each other absent the pattern (one subject aware of a growing observer list, vs. N colleagues each potentially aware of N−1 others) shows exactly what complexity each pattern is removing.

Common pitfall: Treating Mediator as "just Observer with more participants" — Mediator's colleagues can both send AND receive coordinated reactions through the hub, while Observer's observers never affect the subject or each other, only react to it.

Source: Gamma, Helm, Johnson & Vlissides, Design Patterns, "Observer" and "Mediator" (behavioural patterns).

Question 16 of 28: Observer vs. Mediator Design Patterns

Question 16: Observer vs. Mediator Design Patterns (Part III)