How Does the Observer Pattern Push Updates?

TL;DR

The Observer pattern lets one observable notify many registered observers whenever its state changes. This replaces repeated polling with targeted push notifications, so observers request or receive updates only after a change occurs. The pattern therefore defines a one-to-many dependency in which an observable tracks its subscribers and automatically informs them about relevant state changes.

Transcript

okay we're back today we're going to talk about Observer pattern if you're new to this playlist or new to this channel in this playlist we're talking about all of the patterns in this book head first design patterns so it's something like 12ish patterns one by one by one we'll go through them so if you're not already subscribed be sure to subscribe... Read More

Key Insights

• The Observer pattern is a one-to-many dependency in which one observable object can notify many dependent observer objects after its state changes. The observable occupies the one side of the relationship, while its registered observers occupy the many side.
• Polling is repeated requesting of state or data before the requester knows whether anything has changed. Because the change time is unknown, an observer must continue asking indefinitely and choose a frequency that might be either inefficient or insufficiently responsive.
• Push notification is initiated by the object whose state has changed. Instead of waiting for observers to ask repeatedly, the observable sends a change notification after each relevant transition, allowing every registered observer to respond according to its own needs.
• The observable is responsible for knowing which observers should receive notifications. Observers must register with it before notifications can be pushed, creating the relationship required for automatic updates whenever the observable moves from one state to another.
• A weather station is an example of an observable because its measurements can change over time. A display can act as an observer because it needs to know when new weather data is available and can update after receiving a notification.
• An RSS source and reader illustrate the same relationship. The source changes when an article is published, and the reader wants to know about that event. Registration and notification avoid forcing the reader to ask continuously whether a new article exists.
• Scaling makes polling increasingly wasteful because many interested objects may ask the same source for data at every interval. With the Observer pattern, the source sends notifications to all registered observers only when its state actually changes.
• Observable and subject can refer to the same role in descriptions of the pattern. The presentation prefers observable because it clearly distinguishes the object being observed from the observers that are interested in its changes.

Questions & Answers

Q: What is the Observer pattern in object-oriented design?

The Observer pattern defines a one-to-many dependency between objects. One object, called the observable or subject, changes state over time. Other objects, called observers, register their interest in those changes. When the observable changes state, it automatically notifies all registered observers, which can then update or perform whatever response they require.

Q: How does the Observer pattern replace polling?

The Observer pattern replaces repeated requests with notifications initiated by the changing object. Under polling, interested objects continually ask for state or values without knowing whether new data exists. Under the push approach, the observable waits until its state changes and then informs every registered observer, eliminating requests made when nothing has changed.

Q: Why can polling become inefficient with many subscribers?

Polling becomes inefficient because every subscriber repeatedly contacts the same object, even when its state has not changed. If many subscribers ask at every interval, the number of unnecessary requests grows substantially. The Observer pattern limits communication to actual changes, when the observable pushes a notification to each registered observer rather than answering continuous duplicate requests.

Q: What is the difference between an observable and an observer?

An observable is the object whose internal state changes and whose changes matter to other objects. An observer is an interested object that registers to receive notifications about those changes. The observable maintains knowledge of its subscribers and pushes notifications to them, while each observer decides what action to take after being informed.

Q: How do observers begin receiving state-change notifications?

Observers begin receiving notifications by registering with the observable. Registration gives the observable knowledge of which objects are interested in its state changes. After that relationship exists, the observable can notify all registered observers whenever it enters a new state. Each observer can then retrieve or process the relevant data and update itself as needed.

Q: Why is the Observer pattern a one-to-many relationship?

The relationship is one-to-many because one observable object is connected to multiple observer objects. The observable forms the one side, while all registered observers form the many side. When the one object changes state, it notifies the many dependent objects automatically. The presentation compares this structure with one-to-many relationships shown in entity relationship diagrams.

Q: How does a weather station demonstrate the Observer pattern?

A weather station demonstrates the pattern by acting as an observable whose measurements may change whenever new weather data is collected. One or more displays can register as observers because they need updated measurements. When the station records a state change, it notifies the displays, allowing them to update without repeatedly requesting unchanged data.

Q: Are subject and observable the same role in the Observer pattern?

Subject and observable are used for the object being watched for state changes. The referenced book uses the term subject, while the presentation prefers observable because it more directly identifies the role. The observable can be observed, and observers observe it. Regardless of terminology, this object registers observers and notifies them when its state changes.

Summary & Key Takeaways

• The Observer pattern addresses situations where one object changes state and other objects need to know about those changes. Examples include a weather station supplying measurements to displays and an RSS source alerting a reader when an article is published. The changing object is observable, while interested objects are observers.

• Polling requires interested objects to repeatedly ask whether state has changed or repeatedly retrieve values without knowing whether new data exists. The appropriate polling frequency is difficult to choose, and the problem grows when many objects make repeated requests. Push notifications occur only when the observable actually changes state.

• The pattern defines a one-to-many dependency between objects. Observers first register with the observable, giving it knowledge of its subscribers. When the observable changes state, it notifies every registered observer automatically. Implementations can vary, but the presented UML structure uses observable and observer interfaces to express their respective roles.