observer pattern question #1 (reference to subject)

Alan Isaac aisaac at american.edu
Thu May 8 15:40:25 EDT 2008


> Alan Isaac <aisaac at american.edu> writes:

>> 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





More information about the Python-list mailing list