observer pattern question #1 (reference to subject)

[Alan Isaac]

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

[Ville M. Vainio]

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? ;-)

[Alan Isaac]

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

[Ville M. Vainio]

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.

[Alan Isaac]

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

[castironpi]

On May 8, 4:57*pm, Alan Isaac <[e-mail]:

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.