I've been looking at examples of sequence diagrams for observer pattern but most implement push model where the subject updates the observers. In a pull model how would it be different because technically the subject updates the observers still when there is a change just that the observer triggers the data extraction?


The observer pattern in its very essence a push of notifications. Here the exact wording that defines the pattern's intent according to the GoF (emphasis is mine):

Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically.

The notification is always pushed (via a call to the observers' update()), but the typical scenario (see sequence diagram) requires the observer to pull the state of the object notifying it (via a call to the subject's GetState() or any other getter that provides the info the relevant observer is interested in).

If you would like to only pull, then it's no longer the observer pattern, but the polling pattern:

  • A polling object would pull the state of the subjects from time to time (event driven or time driven). But this might rather be inefficient, since it would pull the data even if it's not changed.
  • An improved polling could maintain a list of "dirty" objects, i.e. objects that changed since the last time the observer was active. When the "poller" is activated, it would then pull only the state of the dirty objects, after what the dirty flag would be reset. However this is far from ideal since it allows only one polling object, or that all polling objects do their job at the same time in order not to miss changes.
  • A more improved version when there are several interested objects, would then be that the subjects register as dirty to all the interested ones. But then you'd be back to traditional observer pattern, where subject notifies the observers. And this is the reason why this pattern was invented.

A slight variant could be not to react immediately on the notification. The observer could very well maintain a list of objects that notified it, and react on the notification (query the states) later, based on a specific event or a timer. The sequence diagram would be the same than for the normal observer, except that the GetState() would be called from a different execution occurence specification that would start upon the relevant event (e.g. a call comming from a Timer object.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.