Re: Consuming your own events.

Frans,

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.

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)

.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, ...

maybe we should just leave it for now; I assume that our development styles differ and that is probably based on our different reference frames.

regards,
  Daniel

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

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