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 re-usability is limited to these Observers.
Pull Model: The subject sends observers detailed information about the change that 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.
Advantages of Pull Agents - They work when the client application is hosted behind a firewall – this is because all of its traffic is outbound. They are simpler to write than Push agents.
Advantages of Push Agents - They are much more efficient than pull agents: messages are only sent when data needs to be sent. They are faster in that a message is delivered as soon as it is available to be delivered – it does not need to wait until the next time the receiver does a poll for the message to be delivered. They are potentially more secure (if set up correctly).
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 re-usability is limited to these Observers.
Pull Model: The subject sends observers detailed information about the change that 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.
Advantages of Pull Agents - They work when the client application is hosted behind a firewall – this is because all of its traffic is outbound. They are simpler to write than Push agents.
Advantages of Push Agents - They are much more efficient than pull agents: messages are only sent when data needs to be sent. They are faster in that a message is delivered as soon as it is available to be delivered – it does not need to wait until the next time the receiver does a poll for the message to be delivered. They are potentially more secure (if set up correctly).
Ref:
Applying Observer Pattern in C++ Applications -
http://www.codeguru.com/cpp/cpp/cpp_mfc/patterns/article.php/c837
Pull vs Push - http://www.sifsupport.com/
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 -
Applying Observer Pattern in C++ Applications -
http://www.codeguru.com/cpp/cpp/cpp_mfc/patterns/article.php/c837
Pull vs Push - http://www.sifsupport.com/
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
