Observer pattern issue

Discussion in 'Java' started by cstratelos@gmail.com, Feb 13, 2006.

  1. Guest

    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
    , Feb 13, 2006
    #1
    1. Advertising

  2. VisionSet Guest

    <> wrote in message
    news:...
    >
    > 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
    VisionSet, Feb 13, 2006
    #2
    1. Advertising

  3. 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
    Robert Klemme, Feb 13, 2006
    #3
  4. 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/computer-lang/java/gui/faq
    http://www.uni-giessen.de/faq/archiv/computer-lang.java.gui.faq/
    Thomas Weidenfeller, Feb 13, 2006
    #4
  5. Guest

    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
    , Feb 13, 2006
    #5
  6. 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
    Robert Klemme, Feb 13, 2006
    #6
  7. Chris Uppal Guest

    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
    Chris Uppal, Feb 13, 2006
    #7
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Beatrice Rutger
    Replies:
    0
    Views:
    708
    Beatrice Rutger
    Jun 5, 2005
  2. mem

    Observer pattern

    mem, May 18, 2004, in forum: C++
    Replies:
    2
    Views:
    525
    adiian
    Jun 4, 2007
  3. Paolino

    An observer pattern application.

    Paolino, Aug 18, 2005, in forum: Python
    Replies:
    0
    Views:
    333
    Paolino
    Aug 18, 2005
  4. Michael Schneider

    weakrefs to functions for observer pattern

    Michael Schneider, Nov 3, 2005, in forum: Python
    Replies:
    3
    Views:
    370
    Alex Martelli
    Nov 3, 2005
  5. Replies:
    5
    Views:
    552
Loading...

Share This Page