Re: Consuming your own events.

> As your initial example shows calling base, or not really, depends on the
> implementation of the base class,
> and as with everything regarding SW-development this has to be controlled by
> the developer. This is part
> of the ´"brittle-base-class" problem since the requirement to call or not to
> call base isn't codified and therefore it can't be verified by the compiler
> and hence it has to be verified by tests. This is also the case why you
should
> avoid deep inheritance if possible.

        It can't be verified by the compiler, though I expect that a developer
knows why s/he takes an action. A method doesn't get overriden by accident,
you deliberately take the action to override a method. You also don't pick
another method, you pick the particular On... method and therefore you have a
reason to do so. I then expect as well that the person doing so knows what the
consequences are and what the contract is for the On.. method. 

        Sure bad things can happen if you forget to call the base' version in
cases where you had to call the base' method. But that's no different than
with calls to methods which do things for you, preprocess data for example.  

        About deep hierarchies: a deep hierarchy is often a smell of over
engineering, true, but I don't see why it would be brittle: if people know
what they're doing (and I expect a professional to know what s/he's doing) why
would it be bad if you override a virtual method to adjust the behavior? Isn't
that the _INTENT_ of the method being virtual in the first place? 

> You are right the pattern is called observer not monitor, I've had my head
to
> far the multi-threaded-bucket for to long. "The Blackboard architectural
> pattern is useful for problems for which no deterministic solution
strategies
> are known" -which is the
>  case when you have a set of unknown size with observers that will "vote"
for
> the outcome of the attempted delete operation. (your collection sample)

        Thanks.

> .NET events are callbacks; nothing less nothing more. They are great for
> notifications but they are really bad for reverse-data-exchange (from the
> notifyee och the notifier). In your simple collection problem, events are
> probably sufficient but for more
>  complex solutions such as 2-pahse-transactions they aren't. Reimplementing
> the event-mechanism seems stupid, but adding additional features isn't. The
> CLR impl lack support for, multithreading, reverse-data-exchange, exception-
> handling, cancel & compensate, ...

        I agree that you can get overboard very quickly if you create a web of
events which are just souped up calls to methods. I see cancellable events as
a group of events (thus the things which happen, not the .net elements) which
can be cancellable with a vote-mechanism with the event raiser calling out to
all listeners if there's an objection to continue, so that party should speak
up now or forever hold their breath ;). 

        If you indeed raise events which carry eventargs which collect data on
the fly, you're not doing things OK, as it's then better to call out to a
manager class which governs the process instead of using a web of objects
which have to know of each other because there's no central command. 

                FB

===================================
This list is hosted by DevelopMentor®  http://www.develop.com

View archives and manage your subscription(s) at http://discuss.develop.com