Re: Observer pattern limitations


Frans Bouma wrote:
Leslie Sanford wrote:


"Gabriel Claramunt" wrote:

<snip>

If you want to discuss oberver pattern limitations you are welcome,
but let's discuss it in the scope of the pattern.
Observer pattern clearly shows the subject and a list of observers,
you have problems with a composition of subjects and observers in a
graph with cycles... IMHO that should be another pattern
(Composition of observers?), also no OO practitioner I know
assembles multiples patterns and expect to work just because
they're patterns. The dirty reads and cycles in the graph are
valid problems but I fail to see how they're in the scope of the
observer pattern. Maybe if you explain a little more about the
problem, we can help to find a better solution.

I pretty much agree, but just wanted to add this:

The Observer pattern has become the de facto way for objects to
communicate, at least with prefab objects that are often found in
libraries. For example, I use C#, and the .NET Framework is full of
components that have "events" for notifying interested parties when
something happens or changes with the components. Writing my own
libraries, I've often followed this pattern when creating components.
The Observer pattern is ubiquitous as it is built into the .NET
languages.

I've to add that Microsoft insists that events are raised in no
particular order. At no point in time should a developer assume events
are raised in a particular order, even if it seems that way.

That sounds like a good approach.


That's essential in this case, as it clearly shows that the observer
pattern is implemented correctly, however it can be mis-used if the
developer ASSUMES there's an order in the events, like mr.
Barret-Lennard has done.

I assume no such thing. On the contrary. That's what allows me to
pick a "counter example".


The promise of this architecture, and indeed the whole "component"
idea, is that you can approach programming in a "plug-and-play"
fashion. Take existing components, hook them together via events and
event handlers, and you have a lot of your work already done. Plus,
there is the promise of being able to reconfigure your application on
the fly as you switch out components.

But there are a whole host of issues that arise when you begin
programming this way. For example, in a multithreaded environment, you
need to know if an event notification is taking place on a different
thread than the one in which you wish to handle it. If so, you may
need to marshal said event to your thread. And what about exceptions?
If you run into an exceptional situation in an event handler, how do
you deal with it? If you throw an exception from the handler, where
will it wind up? It may pass through the subject who's in the middle
of notifying its observers. This could have all kinds of consequences.

My point is not that the Observer pattern is flawed but that it should
be used with care. The above problems have answers and can be solved,
but they do require that you first ask the right questions and then
look for suitable answers.

exactly. If you run into the problems you describe, it isn't due to
the observer pattern, but to different problems which likely ask for a
different pattern or if you consider all the problems combined, you
might want to opt for a different set of patterns altogether.

So we all agree.


Similar problems occur when an object exposes properties to set which
affect the state of the object. If you then call a method after that,
can you assume that the state of the object matches the reason you call
the method? Unclear. If you need that, the pattern used is not the
correct one.

My participation in this thread, however, has been to explore
possibilities that will let us program from a higher level, so to
speak. Are there approaches that will let us more easily configure
components together without worrying about the issues that have been
raised in this thread? Can we find a generalized approach that can be
used in a variety of situations that will take care of these issues
for us or make them simply disappear? At the very least, is there a
set of heuristics that can be applied to the Observer pattern to make
it more robust? Those are the questions I'm interested in, and this
thread has been interesting along those lines.

I think people should take a step back and drop the whole 'pattern'
approach until they've figured out which problems they want to solve in
the first place. Too many developers design their software by
connecting patterns with patterns like lego blocks, but that's not what
they're all about.

I agree with that as well.

Cheers,
David Barrett-Lennard

.

Relevant Pages

  • Re: Observer pattern limitations
    ... The title of the thread was "Observer pattern limitations". ... ""This reflects a sorry lack of formalism in the OO community" ...
    (comp.object)
  • Re: Observer pattern limitations
    ... The title of the thread was "Observer pattern limitations". ... The dirty reads and cycles in the graph are valid problems but I fail to see ...
    (comp.object)
  • Re: MVC-Pattern in my C# GUI !?!
    ... | May I advise that you can't "add" MVC in an application, ... the MVC pattern to an existing app that currently doesn't use the MVC ... | You should not have anything other than visual controls on your forms, ... | have wrapper classes that implement the Observer pattern and carry out the ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: c# events - 2 independent classes listening to each other?
    ... >>What you are referring to is the Observer pattern. ... I just read about the mediator pattern and it does seem to ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: The difference table of pures in the 3n+1 problem!
    ... in the pattern created by the non trivial impures. ... table that shows only the impure exceptions ... trivial odd exceptions are the most important ... Ken's LDAs and my Sequence Vector system. ...
    (sci.math)