By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
425,749 Members | 1,615 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 425,749 IT Pros & Developers. It's quick & easy.

observer pattern question #1 (reference to subject)

P: n/a
I have two questions about the "observer pattern" in Python.

This is question #1. (I'll put the other is a separate post.)

Here is a standard example of the observer pattern in Python:

http://en.wikipedia.org/wiki/Observer_pattern

Contrast with this rather standard discussion:

http://www.dofactory.com/Patterns/Pa...er.aspx#_self1

The difference I am focusing on is that in the latter,

the observer (investor) maintains a reference to the

subject (stock).

(Many questions can be raised of course: see the discussion at

http://aspn.activestate.com/ASPN/Coo...Recipe/131499).

Is anything lost by not maintaining this reference (other

than error checking ...)? If I feel the observer needs

access to the subject, what is wrong with just having the

subject pass itself as part of the notification?

Thank you,

Alan Isaac
Jun 27 '08 #1
Share this Question
Share on Google+
5 Replies


P: n/a
Alan Isaac <ai****@american.eduwrites:

Is anything lost by not maintaining this reference (other

than error checking ...)? If I feel the observer needs

access to the subject, what is wrong with just having the

subject pass itself as part of the notification?
It reduces the number of places the observer can be called from,
because now the event source is part of the function signature. If you
omit the event source in the signature, you gain looser coupling -
it's the observer business to create the dependency.

Also, consider the situation where you want all investors to refresh
their idea about stock prices (because of, short network
failure). It's easy to run through a list of them and call update()
for everybody, while it's not so easy to find out what stock the
investor is observing (that's the investors business!) and pass that
object to the investor in the call.

Are these school questions btw? ;-)
Jun 27 '08 #2

P: n/a
Alan Isaac <ai****@american.eduwrites:
>Is anything lost by not maintaining this reference (other
>than error checking ...)? If I feel the observer needs
>access to the subject, what is wrong with just having the
>subject pass itself as part of the notification?


Ville M. Vainio wrote:
It reduces the number of places the observer can be called
from, because now the event source is part of the function
signature. If you omit the event source in the signature,
you gain looser coupling - it's the observer business to
create the dependency.


As I said, I'm not a programmer, and perhaps as a result,

I have questions about both of your points. I'll stick with

the stock example, since it is concrete.

Note that the observor/listener in the example at

<URL:http://en.wikipedia.org/wiki/Observer_pattern>

does not create a reference to the subject.

So in this context I take you to be saying something like

the following: "OK, here's the pattern, now your listener

wants to know the event source, do not ask something new the

subject to respond to that need. That is unnecessary

coupling. Instead, just rewrite your listener to maintain

a reference to the subject."

Do I have that right?

It seems to me that this response begs the question.

That is, an appropriate reply seems to be: here is a related

pattern, call it observer2. In the observer2 pattern, the

subject has a getState method and always passes itself when

it notifies the observer. Now: in what sense does this

require closer coupling?


Also, consider the situation where you want all investors
to refresh their idea about stock prices (because of,
short network failure). It's easy to run through a list of
them and call update() for everybody, while it's not so
easy to find out what stock the investor is observing
(that's the investors business!) and pass that object to
the investor in the call.


I seem to be missing your point here.

Let's keep using the stock/investor example.

When the network comes up, each stock should notifies

everyone in its list of listeners. It either passes itself

or does not. In either case, the investor took care of hir

side of the business by registering as a listener.

If the stock does not notify all its registered investors,

it is breaking its contract. So, what is the problem?

Or to put it a different way, your suggestion that the

investors should have to *pull* this information from the

stocks seems out of step with the observer pattern, where

the stocks should be pushing this information to the

investor.

Again, talk of stocks and investors is just a convenient

short hand for discussing the observer pattern. I do not

care about stocks/investors more than other applications.
Are these school questions btw?


No, sorry. But I still appreciate the feedback.

Cheers,

Alan Isaac
Jun 27 '08 #3

P: n/a
Alan Isaac <ai****@american.eduwrites:
the following: "OK, here's the pattern, now your listener
wants to know the event source, do not ask something new the
subject to respond to that need. That is unnecessary
coupling. Instead, just rewrite your listener to maintain
a reference to the subject."

Do I have that right?
Not really. It has to be determined case-by-case. Note that I'm not
arguing *for* not passing "subject" on notification, just trying to
elaborate on situations that might want to choose that route.
It seems to me that this response begs the question.
That is, an appropriate reply seems to be: here is a related
pattern, call it observer2. In the observer2 pattern, the
subject has a getState method and always passes itself when
it notifies the observer. Now: in what sense does this
require closer coupling?
It creates stronger connection between the subject and observer,
thereby reducing the amount different of places that can call the
observer (I don't mean different stock, but altogether different
places - say, a central stock controller that can broadcast the change
in several stocks at the time by stock id, once per second).

This is not really a feature of the observer pattern, both approaches
are somewhat valid observer patterns, depending on problem domain. If
you think it makes sense in the first place to have ONE reference to
the subject in observer, it's probably a workable approach - but in
case of stocks, you are probably monitoring several stock objects, so
the stock should probably pass itself to the observer (so that you
don't need to check all stocks every time something changes!).

Of course this stock thing is a bad example for this case, because you
have several stocks per investor. It's analogous to a typical UI
scenario where you have several widgets forwarding events to one big
observer - and they *do* provide the event source and event type.
Or to put it a different way, your suggestion that the
investors should have to *pull* this information from the
stocks seems out of step with the observer pattern, where
the stocks should be pushing this information to the
investor.
It's not necessarily the observer that has the interesting
information. It's quite typical to have general "catch-all"
notifications than report observers that "something has
chanced somewhere, so you should refresh your data".

All in all, though, the right solution should be obvious from the
problem at hand.
Jun 27 '08 #4

P: n/a
Ville M. Vainio wrote:
in case of stocks, you are probably monitoring several
stock objects, so the stock should probably pass itself to
the observer


OK. This is related to my question #2 (in a separate

thread), where I'd also appreciate your comments.


analogous to a typical UI scenario where you have several
widgets forwarding events to one big observer - and they
*do* provide the event source and event type.


That is a helpful comparison.


All in all, though, the right solution should be obvious
from the problem at hand.


For CS types, maybe. The rest of us are just trying to get

things done without as much background and context.

Thanks,

Alan
Jun 27 '08 #5

P: n/a
On May 8, 4:57*pm, Alan Isaac <ais...@american.eduwrote:
Ville M. Vainio wrote:
in case of stocks, you are probably monitoring several
stock objects, so the stock should probably pass itself to
the observer

OK. *This is related to my question #2 (in a separate

thread), where I'd also appreciate your comments.
analogous to a typical UI scenario where you have several
widgets forwarding events to one big observer - and they
*do* provide the event source and event type.

That is a helpful comparison.
All in all, though, the right solution should be obvious
from the problem at hand.

For CS types, maybe. *The rest of us are just trying to get

things done without as much background and context.

Thanks,

Alan
My local vernacular calls them "carfulls" of people, which analogy to
the body of collective man, extends pretty far.

It's not the gas pedal we hate! I'm schedule more coasting on shore.
Jun 27 '08 #6

This discussion thread is closed

Replies have been disabled for this discussion.