Observer
Observer lets a publisher notify registered subscribers without naming every concrete listener in its update logic. Subscription lifetime and notification ordering are part of the contract.
What you’ll understand
- Observer lets a publisher notify registered subscribers without naming every concrete listener in its update logic. Subscription lifetime and notification ordering are part of the contract.
- Keep subscription registration in the publisher and iterate a stable subscriber snapshot during notification.
- Evaluate the tradeoff: Synchronous observers can slow the publisher or cause reentrant updates. This small model preserves registration order and treats unsubscription before publishing as effective immediately.
Useful first: Classes and Objects
The idea and when to recognize it
Observer lets a publisher notify registered subscribers without naming every concrete listener in its update logic. Subscription lifetime and notification ordering are part of the contract.
- Requirement: A stock publisher notifies subscribed displays when a quantity changes.
- Change to anticipate: Unsubscribe one display before the next update and notify only current subscribers once.
- Design goal: Keep subscription registration in the publisher and iterate a stable subscriber snapshot during notification.
Start with the concrete problem
A stock publisher notifies subscribed displays when a quantity changes.
Unsubscribe one display before the next update and notify only current subscribers once.
| Direct implementation | Revised design |
|---|---|
| Keeping a stale subscriber list ignores opt-outs and delivers unwanted events. | Keep subscription registration in the publisher and iterate a stable subscriber snapshot during notification. |
| The baseline case can hide the problem. Compare the extension and boundary fixtures before accepting this design. | Synchronous observers can slow the publisher or cause reentrant updates. This small model preserves registration order and treats unsubscription before publishing as effective immediately. |
Responsibilities and contracts
Keep subscription registration in the publisher and iterate a stable subscriber snapshot during notification.
- StockPublisher: Owns subscriptions. Public operations: subscribe(id), unsubscribe(id), publish(value)
- Display: Receives an update. Public operations: update(value)
Read the design
Select a participant to inspect its responsibility and public operations. Follow the labeled relationships; an arrow indicates direction, while the legend distinguishes ownership, substitution, and temporary use.
Preparing the design walkthrough…
Follow the interaction
Choose a supplied workload and compare the direct and revised implementations. Step through the same operation in both languages. Object values are recorded after each highlighted statement; previous steps remain unchanged.
Preparing the design walkthrough…
Implementation and expected output
Read the complete example alongside its input and expected output. The implementation selector changes the displayed program; the language selector preserves your current scenario and playback position.
Preparing the design walkthrough…
Try the idea in another setting
A document editor can notify an outline view and a word-count view after an edit.
- Name the new client contract before adapting the example.
- Identify which state belongs to each object and who controls its lifetime.
- Write one normal case and one boundary case before extending the design.
Tradeoffs and interview takeaways
Synchronous observers can slow the publisher or cause reentrant updates. This small model preserves registration order and treats unsubscription before publishing as effective immediately.
Common mistake: Keeping a stale subscriber list ignores opt-outs and delivers unwanted events.
- Explain the choice: Keep subscription registration in the publisher and iterate a stable subscriber snapshot during notification.
- Challenge your choice: Synchronous observers can slow the publisher or cause reentrant updates. This small model preserves registration order and treats unsubscription before publishing as effective immediately.
- Describe a requirement that would make the simpler implementation sufficient.
Design challenge and knowledge check
Preparing the design walkthrough…