Observer Pattern - Push vs Pull Model

The Subject and the Observers can interact using a Push Model or a Pull Model

Push Model: The observer is notified that a change has occurred and must find out itself what changes have occurred.

In this model, the Subject pushes the state changes to the Observers. Push model can be used when all the Observers are interested in common state changes. Observers have no choice other than receiving the pushed data. Push model cannot be used with large amount of data, as an Observer may not be interested in all the data that is being pushed. Also, the Subject must know something about the Observer to which it is pushing the data. Therefore, the Observers have to comply with a standard interface required by the Subject and the Subject’s reusability is limited to these Observers.

Pull Model: The subject sends observers detailed information about the change tha has occurred (in the simplest case, the entire new state itself).Pull model is simple, but leads to further requests from the observer to the subject.

In this model, the Subject notifies the state change to the Observers and the Observers pull only the required data from the Subject. Pull model is more flexible and the Observers can pull only the required data. But, more than one method call is required to implement the pull model. The first method call is for change notification from the Subject to all its Observers and an interested Observer must call at least one more method to pull the data.

In a very dynamic environment, the state of the Subject can change between these two calls, that is before the Observer pulls the data. Therefore, the Subject and the Observers may not be in sync. Above all, the Observers call specific methods to pull the required data and it is up to them to figure out what is changed without getting much help from the Subject.

Push vs Pull

The push/pull note is more about how information about what happened is transferred once the notification need arises. push/pull model differ in different sorts of coupling associated with each approach.

Push requires that the Subject know what information the various Observers may need. So to avoid Subject knowing about individual Observers, one needs to provide a superset of information that includes everything observer might need.

Pull eliminates that coupling on Subject's part but it forces the Observer to ask explicitly for the Subject state data that it needs. Presumably the Observer will never need anything that isn't a public responsibility of Subject, so the pull model tends to be fairly benign and is commonly used when the relevant state data is nontrivial. The downside is that one needs to deal with the synchronization problem.

From Event Channel perspective:

Push Model - Suppliers generate events and actively pass them to an event channel. In this model, consumers wait for events to arrive from the channel.

Pull Model – A consumer actively requests events from the channel. The supplier waits for a pull request to arrive from the channel. When a pull request arrives, event data is generated and returned to the channel.

Ref:

Applying Observer Pattern in C++ Applications -
http://www.codeguru.com/cpp/cpp/cpp_mfc/patterns/article.php/c837

Observer Pattern from IBM - http://www.research.ibm.com/designpatterns/example.htm

Pull vs. Push models for UI updates - http://ayende.com/Blog/archive/2009/02/16/pull-vs.-push-models-for-ui-updates.aspx

Clarification on MVC Pull and MVC Push - http://www.theserverside.com/patterns/thread.tss?thread_id=22143

http://www.csi.ucd.ie/staff/meloc/DesignPatterns/notes/Observer6.pdf

http://groups.google.com/group/comp.software.patterns/browse_thread/thread/5d0f7094bde7c85e

http://www.coderanch.com/t/441195/OO-Patterns-UML-Refactoring/Observer-Pattern-Push-versus-Pull