TableReport is an Observer that records each player’s outs and hit types, then prints a game table when 27 outs have occurred. It subscribes to BaseballReporter and processes each arriving event in update(). section 12.1.3
Its design separates event production from table-specific processing:
- Receives notifications through the common Observer interface instead of requiring BaseballReporter to call a TableReport-specific method. section 12.1.3
TableReport in a game run
The tester creates a BaseballReporter, attaches LogReport, GraphReport, and TableReport, then calls distribute_content(). BaseballReporter generates events until the game ends; TableReport accumulates each player’s hit categories and prints its table at the final out.
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.
Shows how TableReport fits into the publisher–subscriber flow from BaseballReporter through Subject and Observer. section 12.1.3
