The Observer pattern solves a publisher–subscriber problem: one subject produces data, while multiple observers process each update independently. The subject tracks subscribers but does not depend on their implementations or purposes. section 12.0 section 12.1
A typical implementation provides:
- A Subject stores observers and exposes attach() and detach() operations. section 12.1.3
- An Observer interface requires an update() method for receiving notifications. section 12.1.3
- When the subject receives new state, notify() calls update() on every subscribed observer. section 12.1.3
- Observers may fetch the subject’s current state after notification and decide how to use it. section 12.1.3 section 12.2
Baseball reports
BaseballReporter subclasses Subject and publishes each hit Event. LogReport records events immediately, TableReport accumulates per-player statistics until the game ends, and GraphReport counts hit types for a final bar chart. A FanClubReport can subscribe later for one named player without changing BaseballReporter. section 12.1 section 12.1.3
Figure 12.5 The generic model of the Observer Design Pattern. Compare with figure 12.3. During run time, we can add subscriber Observer objects to or remove them from the publisher Subject class’s collection of Observer objects. Whenever an ExemplarSubject changes state, the Subject class’s notify() method iterates over the observers collection and calls method update() of each ConcreteObserver object. Each ConcreteObserver can then choose to call the get_state() method of the ExemplarSubject class to get the new state.
Use the generic model to connect subject state changes, runtime subscription management, notification, and observer-controlled state retrieval. section 12.1.4
