Re: Observer pattern limitations


Frans Bouma wrote:
David Barrett-Lennard wrote:


Frans Bouma wrote:
David Barrett-Lennard wrote:
Leslie Sanford wrote:
"David Barrett-Lennard" wrote:
Frans Bouma wrote:

Add to that that an observer is simply an ... observer! so
acts upon >> a change of another object, and you are in for a
deep thinking >> process. Your example suggests that when X
changes, Y should be >> updated at any time BEFORE Z reads Y
again, but that's nonsense. If >> that's a requirement, you've
implemented your software with the wrong >> pattern and you
should use a state machine setup.

Can you please state what point you are actually making here?

Not speaking for Frans, but it seems to me that if the event
notification order is important, perhaps a better approach
would be to design the objects involved as state machines. With
the above example, instead of Z reading Y's cache, Y raises an
event when its cache has changed. Z subscribes to this event.

So as a state machine, Z transitions through a series of states
in response to events from X and Y. Say it receives an event
from X first. It transitions to a state indicating that it has
been notified by X but not Y; call it the X_NOT_Y state. It then
receives an event from Y indicating that Y's cache has changed.
Z transitions to another state; call is X_AND_Y. Z is now ready
to do something, whatever that something is.

If Z is not aware of the dependency between X and Y, then it
assumes that if it receives a notification from either of these
inputs it will be "ready to do something".

Remember that any solution has to be related back to contracts in
the design. Consider that we have methods X::Get(), Y::Get() and
Z::Get(). What's the precise contract on these methods? How do
you know when you can safely call them?

Why don't you understand that your example underlines your lack of
understanding between design / ideas and implementation
(application of the design/ideas) ?

As I said in my post, which you carefully read, replied to but also
found irrelevant (?): if the pattern gives implementation problems:
the pattern is not suitable for the problem and you have to look for
another pattern OR you have simply done a bad job implementing the
pattern. It does NOT mean the pattern is flawed.

You also can't proof a pattern is flawed with solely implementation
examples, because the flaw is always implementation related: if you
want to proof a pattern is flawed, proof it with formal examples,
not with implementation related material.

And with the 'observer pattern', I would seriously advice you to
not invest time in trying to proof that it is flawed as it is a
pattern which is very well designed but in the hands of someone who
applies it to the wrong problem it can bite you.

For example your example with x, y and z shows that there's an
order in the actions. If there's an order in the actions, you have a
statemachine matching problem, so a statemachine is very well suited
for that problem. STILL Keeping the observerpattern as THE pattern
to use in that situation is thus stubborness and stupid. That's ok,
we all are stupid and stubborn from time to time.

We need something more formal? A framework in
which certain constraints are enforced to avoid bugs?

We need provably correct algorithms that work with arbitrary
dependency graphs. There is actually some literature on this. Eg
Hudson has an interesting algorithm. The OO community should
investigate, and see how OO can do it properly.

A is observed by B. A raises changed event/signal. B acts upon that
signal/event. DONE.

That's the observer pattern in a nutshell. Nothing more, nothing
less. Whatever is depending on B is not important to B nor is it
important to A. If that would be the case, it would also be
important for A that B is observing it, which would make it a
DIFFERENT problem and thus not sufficient for the observer pattern.

Why you keep going on and on about this is beyond me.

I expect lots of things are beyond you and I feel sorry for you.

heh, yeah, well, let's say that it's not me who has a problem with the
observer pattern, David. I tried to explain to you why you have it
backwards and why your examples don't make sense. You refuse to listen
and after a while we end up with posts like the one above. That's
unfortunate, but I don't have unlimited time to argue with you till
oblivion about a topic which is so utterly clear and simple to
understand. If you refuse to accept even ONE argument from others, I
can only draw one conclusion: you're not looking for an answer, as you
already think you know the answer.


I don't respond because I believe you merely present straw man
arguments. There is nothing that you say that I disagree with, apart
from your implication that I'm wrong. We agree that the observer
pattern has a limited scope. Within that scope it works fine, and
outside that scope it doesn't.

In order to find examples where the observer pattern can't be used,
you obviously have to define use cases that are outside its scope.
That doesn't mean I don't understand that a pattern should only be used
when it works!

I'm sorry I've insulted you; my excuse is that I've found you posts
inflammatory.

Cheers,
David Barrett-Lennard

.

Relevant Pages

  • Re: Is this realization an instance of the Observer Pattern
    ... not an instance of an observer pattern. ... visiting several repositories). ... RepositoryServiceProvider - abstract class (Subject -- in the Observer ... of the search agents ...
    (comp.object)
  • Re: Observer pattern limitations
    ... Add to that that an observer is simply an ... ... to design the objects involved as state machines. ... found irrelevant: if the pattern gives implementation problems: the ... B acts upon that ...
    (comp.object)
  • Re: Is this realization an instance of the Observer Pattern
    ... I am very new the Design Patterns way of thinking about architectures. ... Currently there are 2 kinds of repositories in the picture. ... RepositoryServiceProvider - abstract class (Subject -- in the Observer ... based on the observer pattern. ...
    (comp.object)
  • Re: pre-PEP generic objects
    ... "proxy" that exposes only the desired attributes. ... Another use case is when one wants to implement the "observer" pattern ... blog: http://rascunhosrotos.blogspot.com ...
    (comp.lang.python)
  • Re: SAA OBSERVING: My first Caroline Herschel object!
    ... It is much easier to be an observer with a goto 'scope ... saying that you enjoy star hopping and learning the sky intimately. ...
    (sci.astro.amateur)