The Observer pattern solves a publisher–subscriber problem: one component produces data while multiple components consume it independently. The publisher does not need to know how subscribers process the data. section 1.4.5 section 12.0
Baseball reports
A BaseballReporter produces hit events during a game. LogReport prints each event immediately, while GraphReport and TableReport accumulate events for reports generated later. A FanClubReport can subscribe for one player, react to a matching event, and detach itself. section 12.1 section 12.1.3
A practical implementation separates publishing from observing:
- Subject stores the current subscribers and provides attach(), detach(), and notify() operations. section 12.1.3
- Observer defines update(), which every subscriber implements for its own response to new content. section 12.1.3
- The concrete publisher inherits from Subject, creates or receives new content, and calls notify(). section 12.1.3
- notify() iterates over subscribed observers and invokes update() polymorphically, allowing each observer to process the content differently. section 12.1.3
- Subscribers can obtain the current event from the publisher when they need its details, then may remain subscribed or detach. section 12.1.3
This arrangement creates a one-to-many dependency without hardcoding report classes into the publisher. New subscribers can be added or removed without changing the publisher’s code, while each subscriber owns its processing behavior. section 12.2
Figure 12.3 This version of the application is modeled from the Observer Design Pattern. The content publisher BaseballReporter is a subclass of Subject, and each report class implements interface Observer. Member variable observers of class Subject is a vector of subscribed observers. Each time BaseballReporter uses EventManager to create a new Event object, it points private member variable current_event to the object. Then it calls the notify() member function of superclass Subject, which iterates over the observers vector and calls the update() member function of each subscribed subscriber. Each subscriber can then decide whether to call member function get_current_event() to get the current Event object. The grayed-out portions of the diagram have not changed logically from figure 12.2.
Use the architecture diagram to trace the flow from BaseballReporter through Subject.notify() to each report’s Observer.update() method. section 12.1.3
