| View previous topic :: View next topic |
| Author |
Message |
mariatjahjadi@gmail.com
Guest
|
 Posted: Thu Jan 03, 2008 7:22 am Post subject: pull vs push in observer pattern |
 |
|
is there someone who can help to to understand pull and push in
observer pattern? |
|
| Back to top |
|
 |
| |
Ads |
Advertising
Sponsor
|
|
H. S. Lahman
Guest
|
| Posted: Fri Jan 04, 2008 3:38 am Post subject: Re: pull vs push in observer pattern |
|
|
Responding to Mariatjahjadi...
| Quote: |
is there someone who can help to to understand pull and push in
observer pattern?
|
The implementation note about push/pull is really orthogonal to the
basic pattern. The goal of the pattern is to simply notify various
software entities (ConcreteObservers) that something has changed (in the
ConcreteSubject).
The push/pull note is more about how information about what happened is
transfered _once the notification need arises_. In the Push model, the
Subject can send all <possibly> relevant information along with the
original notification. In that case there is no need for the GetState
query by the Observer because the notification message already has
everything the Observer needs to know.
In the Pull model the Observer queries the Subject about what happened
via GetState. This might be useful when different Observers need to know
different things about the change. However, it can lead to problems in
asynchronous/concurrent environments because the Subject's state might
change again between the time the original announcement was issued and
when the Observer gets around to issuing its query. Then the state
returned by GetState may no longer be the state announced by the
original broadcast message.
I believe the point of the push/pull discussion was that there are
different sorts of coupling associated with each approach. Push requires
that the Subject know what information the the various Observers may
need. So to avoid Subject knowing about individual Observers, one needs
to provide a superset of information that includes everything /any/
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
above in some contexts.
--
There is nothing wrong with me that could
not be cured by a capful of Drano.
H. S. Lahman
hsl@pathfindermda.com
Pathfinder Solutions
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
"Model-Based Translation: The Next Step in Agile Development". Email
info@pathfindermda.com for your copy.
Pathfinder is hiring:
http://www.pathfindermda.com/about_us/careers_pos3.php.
(888)OOA-PATH |
|
| Back to top |
|
|
| |
Ads |
Advertising
Sponsor
|
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
