This week's book giveaway is in the Mac OS forum.
We're giving away four copies of a choice of "Take Control of Upgrading to Yosemite" or "Take Control of Automating Your Mac" and have Joe Kissell on-line!
See this thread for details.
The moose likes OO, Patterns, UML and Refactoring and the fly likes Observer Pattern: Push versus Pull implementation Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


JavaRanch » Java Forums » Engineering » OO, Patterns, UML and Refactoring
Bookmark "Observer Pattern: Push versus Pull implementation" Watch "Observer Pattern: Push versus Pull implementation" New topic
Author

Observer Pattern: Push versus Pull implementation

aditee sharma
Ranch Hand

Joined: Jul 22, 2008
Posts: 182
Hi,
It is understood that Push means that the Subject always updates the Observers with all the attributes all the time, whereas in Pull, the Observers can extract the particular attributes that they need.

Would it be correct to say the following about the implementation of Observer pattern?
The difference between implementation of Push and Pull flavors of Observer pattern is that
1)in pull, the Subject has getter and setter methods for the attributes that are being observed and
2) the signature of update method (i.e the method in Observer that is called by the Subject to pass the information update)
contain the Subject as an argument instead of the all the attributes.The Observer can then pull the information from Subject by getter methods.

Source: Head First Design Patterns--> Chapter 2 : Observer Pattern --> WeatherData example

Hong Anderson
Ranch Hand

Joined: Jul 05, 2005
Posts: 1936
Are you sure you understand correctly?

Setters/Getters have nothing to do with Observer pattern.

For example, I have Model1 as Subject, and Screen1, Screen2, Screen3 as Observers. When Model1's data has been changed, it will notify to Screen1, Screen2 and Screen3 (registered Observers).

I don't know about Push/Pull, but I think it's strange and very bad design, if Observer can pull data from Subject, because it will introduce tight-coupling between Observer and Subject which contradict the intention of the Pattern.

Observer and Subject will know each other via interface only, it'll not know what is the implementation.
This means that Screen1 just know that it register to ISubject (don't know it is Model1), likewise Model1 just know that it has 3 IObserver, but doesn't know what they are.


SCJA 1.0, SCJP 1.4, SCWCD 1.4, SCBCD 1.3, SCJP 5.0, SCEA 5, SCBCD 5; OCUP - Fundamental, Intermediate and Advanced; IBM Certified Solution Designer - OOAD, vUML 2; SpringSource Certified Spring Professional
Dawn Charangat
Ranch Hand

Joined: Apr 26, 2007
Posts: 249
The difference between push and pull here is just how much flexibility and liberty the observers have on the observable.

Push means that the observable will always push the data to observers, whether they need it or not.
Pull : Observers have the liberty of reaching for the data which makes sense for them [I mean, they might be observing a particular field, but only need to be notified if the field crosses some threshold], and hence can reduce on network traffic, and your application performance.

That apart, I dont think there is any major change required in the API design of the same.
aditee sharma
Ranch Hand

Joined: Jul 22, 2008
Posts: 182
Kengkaj Sathianpantarit wrote:Are you sure you understand correctly?

Setters/Getters have nothing to do with Observer pattern.

In the case mentioned from the book, they do matter.
I am not asking about whether push is better than pull or vice versa.
My question is about the implementation.
How is the implementation of pull different than push ?
If any one can explain from the WeatherData example given in the book or provide another complete example, that will really help.
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
[quote=Kengkaj
I don't know about Push/Pull, but I think it's strange and very bad design, if Observer can pull data from Subject, because it will introduce tight-coupling between Observer and Subject which contradict the intention of the Pattern.


In fact, using the push variant leads to tighter coupling of the Subject to the Observers, because the Subject needs to know which information the Observers are (or might be) interested in.

I'm actually often using a variant where the update method has no parameters at all. The Observer simply knows which Subject it is observing and can pull information as needed directly. Often these Observers are implemented as anonymous inner classes.


The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Dawn Charangat
Ranch Hand

Joined: Apr 26, 2007
Posts: 249
But Ilja, if we use some dynamic dependency mechanism, life dependency injection, can't we still have the observers and observables decoupled... and hence make benefit out of the pull mechanism ?
I dont have a lot of experience architecting systems, but what could go wrong in that case... ? I mean there is enough decoupling in that condition...right?
Hong Anderson
Ranch Hand

Joined: Jul 05, 2005
Posts: 1936
Ilja Preuss wrote:
In fact, using the push variant leads to tighter coupling of the Subject to the Observers, because the Subject needs to know which information the Observers are (or might be) interested in.

I don't think so, if Subject knows only Observer Interface, and Observer knows only Subject Interface, there will be no tight coupling.
Parameters are part of interface, but that it only thing Subject know about Observer, it's not tight-coupling, because it knows only interface, not implementation. For example, Subject doesn't know an object that it'll call update(ScreenEvent) is TableScreenListener, ListScreenListener, TreeScreenListener, MatrixScreenListener, but it just know that it's IScreenListener.

However, I think tight-coupling can happen or not happen in both push and pull model.
For instance, for push model, if we have update(ISubject), observers can check instance of and cast to a concrete class anyway.
Or even we use pull model, it's possible that we have getState in ISubject, and observers use ISubject interface, so they needn't to know implementation.

I take back my word that pull is very bad design, because pull is more flexible than parameter even though it is more tight-coupling.
Sorry for confusion.
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Dawn Charangat wrote:But Ilja, if we use some dynamic dependency mechanism, life dependency injection, can't we still have the observers and observables decoupled... and hence make benefit out of the pull mechanism ?
I dont have a lot of experience architecting systems, but what could go wrong in that case... ? I mean there is enough decoupling in that condition...right?


I don't think I understand what you are proposing. Perhaps you could sketch an example? Thanks!
Dawn Charangat
Ranch Hand

Joined: Apr 26, 2007
Posts: 249
You mentioned a tight coupling between subject and observer in case of a pull.

What I suggest is that - If I program to interfaces, or even better, use dependency injection to find the subject and invoke the method on it, wont it make this relation loosely coupled?
aditee sharma
Ranch Hand

Joined: Jul 22, 2008
Posts: 182
Dawn Charangat wrote:But Ilja, if we use some dynamic dependency mechanism, life dependency injection, can't we still have the observers and observables decoupled... and hence make benefit out of the pull mechanism ?
I dont have a lot of experience architecting systems, but what could go wrong in that case... ? I mean there is enough decoupling in that condition...right?


Thanks for your earlier input Dawn. However, I'd request you and everyone else to stick to the topic.
I have no conceptual doubts about how pull is different than pull or the advantages of one over the other.
However, I am not able to accurately appreciate the difference in the implementation of these two flavors from the WeatherData example of the HeadFirst book.
I tried to figure out those differences in my 1st post, but they don't really seem that much relevant.
I mean, we just pass the Subject instance in the update method instead of the observed attributes and we get the pull version ?
Merely encapsulating the observed attributes in the Subject instance doesn't sound very convincing like a different implementation.
Hong Anderson
Ranch Hand

Joined: Jul 05, 2005
Posts: 1936
Dawn Charangat wrote:if we use some dynamic dependency mechanism, life dependency injection, can't we still have the observers and observables decoupled... and hence make benefit out of the pull mechanism ?

I cannot follow. Could you please to give an example? I have no idea how DI helps in this case.
Hong Anderson
Ranch Hand

Joined: Jul 05, 2005
Posts: 1936
aditee sharma wrote:
I mean, we just pass the Subject instance in the update method instead of the observed attributes and we get the pull version ?

aditee, sorry for off-topic.
I checked with Design Patterns [GoF], push model means the subject sends the observers information about the change (it may send itself or change object).
Example of push model:


On the other hand, pull model means the subject just send notification, the observers will find out what is changed later.
Example of pull model:


Hope this helps.
aditee sharma
Ranch Hand

Joined: Jul 22, 2008
Posts: 182
Kengkaj Sathianpantarit wrote:
On the other hand, pull model means the subject just send notification, the observers will find out what is changed later.
Example of pull model:



In HF Book,the implementation of notifyChanged for Pull is something like this :


I have assumed that that notifyChanged in GoF is the similar to update method in HF; i.e it is the Observer method being called by the Subject to inform the former about updates.
John Kimball
Ranch Hand

Joined: Apr 13, 2009
Posts: 96
1)in pull, the Subject has getter and setter methods for the attributes that are being observed and

Sure.


2) the signature of update method (i.e the method in Observer that is called by the Subject to pass the information update)
contain the Subject as an argument instead of the all the attributes.The Observer can then pull the information from Subject by getter methods


I think the Observer's constructor is fairly standard, where the Observer adds itself to the Subject's to-notify list.

But I think which you choose depends on your intent; e.g., you can't tie one observer to multiple subjects via the constructor method, which is probably a good thing in most cases.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Observer Pattern: Push versus Pull implementation