The publish/subscribe model separates a component that produces state or event information from components that process it independently. The publisher does not depend on subscriber implementations or behavior. section 12.0 section 12.2
A useful publish/subscribe design lets:
- The publisher create content at arbitrary times and immediately notify current subscribers. section 12.1.1
- Subscribers choose whether to request new content and decide independently what to do with it. section 12.1 section 12.1.1
- Subscribers join or leave without changing publisher code, while both sides remain unaware of each other’s implementation. section 12.1.1 section 12.2
Baseball game reports
An athletics application publishes hit events as a baseball game progresses. A log report prints each event immediately, while graph and table reports accumulate events and produce summaries after the game. A hardcoded distributor that calls each report’s differently named method works, but adding or removing reports requires changing the distributor and couples it to every report implementation. section 12.1 section 12.1.2
Figure 12.1 An example of the publisher–subscriber model. The publisher component produces hit events that are consumed as they occur by the subscriber components to generate the various reports.
Use the architecture figure to trace hit events from the publisher to independent report subscribers. section 12.1
