Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > Observer pattern issue

Reply
Thread Tools

Observer pattern issue

 
 
cstratelos@gmail.com
Guest
Posts: n/a
 
      02-13-2006
Hello,

I have a question that concerns the Observer Design Pattern.

Why does every book and article that I have read on the topic does not
consider the fact that when the Observable notifies its Observers it
goes through a loop without starting a new thread for its Observer.

What I'm saying is that when you register with an Observable for
notifications, you do not want to depend on other Observers, that may
have already registered before you, to consume the notification
asynchronously.

For instance if there is only one Observer that has registered before
you then when the Observable will go through the loop:

Pseudocode:

foreach Observer o in myObservers
o.notify()

So if that first Observer takes forever to return from the notify()
call, or even worse never returns, you, who registered second, will
never get the notification.

Any thoughts??

thanx
costrat

 
Reply With Quote
 
 
 
 
VisionSet
Guest
Posts: n/a
 
      02-13-2006

<(E-Mail Removed)> wrote in message
news:(E-Mail Removed) oups.com...
>
> So if that first Observer takes forever to return from the notify()
> call, or even worse never returns, you, who registered second, will
> never get the notification.
>
> Any thoughts??


I guess it is the observers responsibility to return quickly, if it needs
longer then the observer should launch its own thread.
I expect there are circumstances where observers can be considered to be
untrusted, and if this were the case then perhaps there is a case for a
threaded notification pattern, especially since everything I have read
always makes clear not to expect the notifications to happen in any
particular order.

--
Mike W


 
Reply With Quote
 
 
 
 
Robert Klemme
Guest
Posts: n/a
 
      02-13-2006
http://www.velocityreviews.com/forums/(E-Mail Removed) wrote:
> Hello,
>
> I have a question that concerns the Observer Design Pattern.
>
> Why does every book and article that I have read on the topic does not
> consider the fact that when the Observable notifies its Observers it
> goes through a loop without starting a new thread for its Observer.
>
> What I'm saying is that when you register with an Observable for
> notifications, you do not want to depend on other Observers, that may
> have already registered before you, to consume the notification
> asynchronously.
>
> For instance if there is only one Observer that has registered before
> you then when the Observable will go through the loop:
>
> Pseudocode:
>
> foreach Observer o in myObservers
> o.notify()
>
> So if that first Observer takes forever to return from the notify()
> call, or even worse never returns, you, who registered second, will
> never get the notification.
>
> Any thoughts??


IMHO there are several reasons against making spawning threads the
default:

- if any of the observers object the operation (=> exception) this won't
work

- the average implementation of a notifier method is quite lean and
usually won't result in those problems you see; for these the overhead of
creating another thread can be significant, especially if done often

- executing notify calls in concurrent threads makes synchronization
necessary all over the place

Kind regards

robert

 
Reply With Quote
 
Thomas Weidenfeller
Guest
Posts: n/a
 
      02-13-2006
(E-Mail Removed) wrote:
> Why does every book and article that I have read on the topic does not
> consider the fact that when the Observable notifies its Observers it
> goes through a loop without starting a new thread for its Observer.


Because it is not relevant. If you need asynchronous notification it is
trivial to notify each subscriber on its own thread ...

.... and it complicates issues significantly, particular because the
observers have to be aware of the thread and need synchronization.

> So if that first Observer takes forever to return from the notify()
> call, or even worse never returns, you, who registered second, will
> never get the notification.


Like with all code, you make certain assumptions. E.g. that an observer
returns in a timely fashion. Like with all code, you don't guard against
every remotely possible failure.

/Thomas
--
The comp.lang.java.gui FAQ:
ftp://ftp.cs.uu.nl/pub/NEWS.ANSWERS/...g/java/gui/faq
http://www.uni-giessen.de/faq/archiv....java.gui.faq/
 
Reply With Quote
 
cstratelos@gmail.com
Guest
Posts: n/a
 
      02-13-2006
What I'm saying is that I cannot rely on other people's implementation
of Observer.
I feel that the pattern is broken.

An equivalent of this in the real world would be a subscription to a
newsletter.
Someone tells you to subscribe to their newsletter, but you will only
get it if all the subscribers before you acknowledge receiving it...

Costas

 
Reply With Quote
 
Robert Klemme
Guest
Posts: n/a
 
      02-13-2006
(E-Mail Removed) wrote:
> What I'm saying is that I cannot rely on other people's implementation
> of Observer.
> I feel that the pattern is broken.


If you take that thought just a step further you're not allowed to use any
libraries - and that includes those that come with the JDK. In every
piece of software there are numerous ways to screw the whole thing up
(actually you don't need multiple people for this ). Does it break
patterns if they are not properly implemented? I don't think so:
implementations are broken - or they use the wrong pattern.

Regards

robert

 
Reply With Quote
 
Chris Uppal
Guest
Posts: n/a
 
      02-13-2006
(E-Mail Removed) wrote:

> Why does every book and article that I have read on the topic does not
> consider the fact that when the Observable notifies its Observers it
> goes through a loop without starting a new thread for its Observer.


Observer pattern is intended to decouple the Observeer from the Observer --
that's to say that in /software engineering/ terms one doesn't depend on the
other. You can make changes to the implementation of either with little risk
of breaking the other.

But that's protecting against changes to the code or to the design. Observer
pattern is /not/ intended to provide protection (at runtime) against buggy or
malicious code. Observers are expected to be coded to conform to the obvious
requirements. If not then they are broken and should be fixed before release.

Now, it isn't absurd at all to consider an extension to the Observer pattern
that /does/ provide more protection. But, (A) it is rarely needed. (B) it
would require complex and slow code in the Observee. (C) It could make the
Observers much more complicated if they couldn't assume that notifications were
still valid at the time they received them. (D) It isn't clear /what/
protection is needed -- depending on the application it might suffice to call
the notification method with a catch-all try/catch block around it; or you
might need to start a new thread for each notification; or you might want to
run the Observer code in a separate OS Process; or even on a different
machine...

The typical Observer implementation is designed to handle the simple and (by
far) most common case. Other implementations can be created at need, but --
and this is point -- there isn't often any need.

-- chris


 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Observer pattern mem C++ 2 06-04-2007 10:32 PM
Questions about the observer pattern samir.vds@googlemail.com Java 5 10-01-2006 07:07 PM
weakrefs to functions for observer pattern Michael Schneider Python 3 11-03-2005 03:24 PM
An observer pattern application. Paolino Python 0 08-18-2005 08:24 AM
JMS or MVC (Observer pattern) in lightweight front end? Beatrice Rutger Java 0 06-05-2005 04:27 PM



Advertisments