Re: Observer pattern limitations


H. S. Lahman wrote:
Responding to Barrett-Lennard...

The observer pattern is fundamental to OO, because it is so common for
objects to need to cache the results of calculations. Display pixels
on the screen essentially represent a cache, and display redrawing is a
common use case for the observer pattern.

Basically I agree with everyone else. The problems you cite are design
problems that exist whether Observer is used or not.

I think this paragraph pretty much describes the issue. You seem to be
regarding Observer as an integral part of a particular problem. But
Observer is a solution to a much simpler and more general problem:
providing notification to other objects that the state of the object in
hand has changed. IOW, it is just an infrastructure for addressing
announcement messages in an asynchronous environment.


Exactly what distinction are you drawing? The observer pattern is
mostly used for providing state change notifications. Who would be
interested in such notifications? I call these dependents or caches.

I am drawing a distinction between the design problems you cited and the
design problem that Observer resolves. The /only/ problem that observer
addresses is that object A needs to know when object B changes and
different members of [A] may need to know in different contexts. Why
object A needs to know that is part of a different design problem, such
as one of those you cited. IOW, the problem context, such as updating a
cache, in which Observer is used it not relevant to its use.

What those other objects do in response to that notification is part of
a different problem solution in the context where Observer is used. It
is only in the design of that solution that your issues arise. That
problem solution will determine any necessary protocols and,
consequently, what messages need to be addressed by Observer.


That is exactly what I'm discussing in my post: how do you make the
observer pattern work correctly in practise.

Solve the design problems you cited first. Then if that solution
requires that some object in that solution needs to know that some other
object changed, Observer may be useful to provide the notification.

In most of the cases you cited you will need to establish some sort of
multi-message protocol between the relevant objects and probably
internal state machines. Those protocols will define what announcement
messages (e.g., events) need to be generated and to whom they should go.
If the execution context changes so that different receivers need to
participate at different times, /then/ you need Observer to provide the
context registration to dispatch the messages to the right object. (If
the receivers don't change with context, then simple associations will
probably be a better solution than Observer.)


Why don't you discuss the actual content of my post, rather than merely
the introduction?

Because the basic problem is failing to separate the concerns of
different problems and the first paragraph most clearly illustrates
that. The rest of the post is about specific problems that are not
directly related to using Observer.

Let me summarise your "argument". You say (in an amazingly long winded
way) that the observer pattern is *only* aimed at supporting
notification between a subject and its observers, irrespective of the
purpose for such notification.

This could be regarded as quite a reasonable definition of the observer
pattern. However the reality is that you have presented a straw man,
which shows that you are either foolish or dishonest or both.

The reader who has not heard of this term may be interested to read
about it in Wikipedia : "A straw man argument is a logical fallacy
based on misrepresentation of an opponent's position. To set up a straw
man or set up a straw-man argument is to create a position that is easy
to refute, then attribute that position to the opponent".

Your argument is that I'm confused about the meaning and purpose of the
observer pattern. Let's look at the evidence...

Let me quote from the GoF book : "INTENT : Define a one-to-many
dependency between objects so that when one object changes state, all
its dependents are notified and updated automatically. ALSO KNOWN AS:
Dependents, Publish-subscribe".

Clearly they define it as relating to the problem of recalculating
dependents, which exactly matches the topic of my original post.


David Barrett-Lennard

.

Relevant Pages

  • Re: Observer pattern limitations
    ... You refer to a notification propagation. ... so a container of observers is an observer. ... some problems have complex dependency ... you don't have formally specified the requirements on what we call cache, ...
    (comp.object)
  • Re: Observer pattern limitations
    ... dependency graph may depend on thousands of inputs, ... complete recurse of the graph is needed just to tell whether it is ... You refer to a notification propagation. ... and an observer decides that it wants to synchronously detach. ...
    (comp.object)
  • Re: Observer pattern limitations
    ... objects to need to cache the results of calculations. ... problems that exist whether Observer is used or not. ... I am drawing a distinction between the design problems you cited and the design problem that Observer resolves. ... IOW, the problem context, such as updating a cache, in which Observer is used it not relevant to its use. ...
    (comp.object)
  • Re: Observer pattern limitations
    ... objects to need to cache the results of calculations. ... problems that exist whether Observer is used or not. ... What those other objects do in response to that notification is part of ... a different problem solution in the context where Observer is used. ...
    (comp.object)
  • Re: Observer pattern limitations
    ... Use asynchronous notification services. ... you might wish to split "data change" and "visual ... an observer decides to attach or detach to/from the subject. ... usually it is a weak reference observer->subject. ...
    (comp.object)