BaseballReporter obtains baseball Event objects from EventMaker and distributes each event to report components. The initial design stores LogReport, GraphReport, and TableReport directly, so distribution names every report-specific function. section 12.1.2
The Observer-based design changes BaseballReporter into an event publisher:
- Inherit from Subject and keep the current Event while distributing content. section 12.1.3
- Generate events until EventMaker returns nullptr, notify subscribers, then delete each event. section 12.1.3
- Expose get_current_event() so notified observers can retrieve the event they need. section 12.1.3
- Let reports subscribe through attach(), unsubscribe through detach(), and receive polymorphic update() calls. section 12.1.3
Adding a fan-club report
FanClubReport subscribes to BaseballReporter, ignores events for other players, retrieves the current event when its chosen player appears, and detaches itself after recording the result. This adds a report without changing BaseballReporter’s distribution loop. section 12.1.3
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.
Trace the publisher, subscriber vector, current event, notification flow, and unchanged event-generation components in the Observer-based architecture. section 12.1.3
