Re: Consuming your own events.

> In this case the guidelines are right and sadly you are wrong =)
> Your proposed solution isn't at all bad; but it is an even more complex
> guideline then the one provided by MS, and even worse it is only your
guideline =(
> Here are a few fast comments:
>
> 1. the protected virtual OnTheEvent( ... ) shall only EVER be used to raise
> the event; no other logic.
> If you implement other logic here, in a class designed for inheritance you
are
> in trouble.

        Erm...
        DataSourceControl.RaiseDataSourceChangedEvent

        So much for guidelines, eh? ;)

        Your reasoning is pretty flawed. The On<Event> methods can also be
seen as methods which are called WHEN the event is raised or WHEN something
happens (which doesn't necessarily have to be resulting in the raise of an
event!)

        Your reasoning seems to be based on what's defined in Winforms. That's
all great, but .NET code is more than just winforms. I for example use
On<SomeEvent> methods to make classes extensible so derived classes can tap in
the pipeline when an event OCCURS in the base class (and which perhaps results
in the raise of an event for subscribers). This thus means that On<SomeEvent>
methods are called by the method which raises the event, they in itself aren't
doing anything.

> 2. Cancelable events are just a hack, remember that an event is a multicast
> delegate. Using OnTheEvent( ... ) you can control if the event is raised.
Sure
> you can get the invocation list and call the clients one at a time; but how
do
> you handle the case
>  where a client further down the list cancels the operation??? Do you
> compensate for it??? If so how???
> Building a Before and After could work, but then you could as well Plain Old
> Callback interfaces (java/COM style) and really get down and dirty =)

        Do you really understand what cancelable events are all about? They're
not events which should be raised AFTER a fact, they're events which are
raised BEFORE something is about to happen. E.g. an object is about to be
removed from a collection. Right before the removal, you raise an OnDeleting
event. All subscribers can check if that removal is allowed. If not, they
cancel the event. But 'event' here isn't the OnDeleting event. 'event' here is
the 'removal'.

        So cancelable events are definitely not a hack, they're a great way to
create a disconnected system where subscribers can tap into a pipeline without
much effort.

> 4. Using base classes are always pretty brittle; It is just simply very very
> very hard to design and implement a class correctly for inheritance.

        No it's not that hard. Operating a hammer is also not that hard, but
if you smash something with it it might break, so be careful.

                FB

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

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