Question 13 of 28: Describing the Observer Pattern in Standard Pattern-Language Form

Question 13: Describing the Observer Pattern in Standard Pattern-Language Form (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.

The GoF catalogue documents every pattern using the same fixed template, so any pattern can be looked up, compared, and applied the same way. Applied here to Observer (Question 16):

• Name. Observer. A short, memorable handle that becomes shared vocabulary between designers ("just use Observer here") without re-explaining the mechanism every time.
• Intent. A one- or two-sentence summary of the problem solved: "Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically."
• Motivation. A concrete scenario illustrating why the problem is hard without the pattern — e.g. a spreadsheet cell whose value feeds both a chart and a summary total, both of which must stay in sync without the cell needing to know about either.
• Applicability. The conditions under which this pattern is the right choice — when a change to one object requires changing others, and the number/identity of the dependents is not known in advance or must be allowed to vary at runtime.
• Structure. A class diagram showing the pattern's participants and their static relationships — here, Subject holding a list of Observer references, with ConcreteSubject/ConcreteObserver as their respective implementations.
• Participants. The named roles and their individual responsibilities — Subject (maintains observers, sends notifications), Observer (defines the update interface), ConcreteSubject (stores state of interest), ConcreteObserver (maintains a reference to its subject, implements the update to stay consistent).
• Collaborations. How the participants interact at runtime — ConcreteSubject notifies its observers whenever a change occurs; each ConcreteObserver may query the subject to reconcile its own state with the subject's.
• Consequences. The trade-offs of using the pattern — benefits (subject and observer can vary/be extended independently, since neither knows the other's concrete class) and costs (a naive implementation can trigger unexpected cascades of updates, and observers are notified even when the specific change is irrelevant to them).
• Implementation. Language- or platform-specific concerns in realizing the pattern — how to order notifications when several observers exist, whether notification is push (subject sends the new state) or pull (subject only signals "something changed," observer queries what), and how to avoid dangling observer references.
• Sample code. A concrete, runnable illustration of the structure in one language.
• Known uses. Real systems already using the pattern — GUI toolkits' event-listener mechanisms, MVC's Model→View notification (Question 18).
• Related patterns. Other patterns often used alongside or confused with this one — Mediator (Question 16, centralizes many-to-many communication rather than one-to-many notification).

The value of the fixed template is that every GoF pattern can be looked up and compared section-by-section: "Applicability" answers "should I use this here," "Consequences" answers "what will it cost me," and "Related Patterns" prevents confusing two patterns whose structures look similar but whose intents differ.