When .NET arrived on the scene it promoted the use of events and delegates to decouple code. Chris Sells had one of the best early stories on how it all works (.NET Delegates:A C# Bedtime Story)*:
Once upon a time, in a strange land south of here, there was a worker named Peter. He was a diligent worker who would readily accept requests from his boss. However, his boss was a mean, untrusting man who insisted on steady progress reports. Since Peter did not want his boss standing in his office looking over his shoulder, Peter promised to notify his boss whenever his work progressed.
For a few years I think we were all infatuated with events. We used them everywhere from the web to the desktop, and even in between. Looking around, you have to wonder if we went down the wrong road.
Consider the people who …
I’m thinking one day soon we will compare writing explicit event code to manual memory management.** Both will be low level details we don’t see in our everyday code.
If so, this will be quite a change from just a few years ago.
--
(*) The start of the story should sound familiar to anyone who worked with COM’s IConnectionPoint, which almost qualifies the story for an award in the horror category.
(**) If this means I never see the INotifyPropertyChanged interface in anyone’s code ever again, then I’ll welcome the new event overlords with open arms.
Comments
Now I'll have bad dreams again.
Thanks!
Thought provoking post KSA. Thanks. :)
1. People dislike the ASP.NET postback model because it's simply a bad fit in the browser, not because it's based on .NET events.
2. Commands are implemented using events, as part of the public API and not as an implementation detail.
3. Aggregator's decouple the source and target, but nearly every single aggregator I've seen uses events, as part of the public API and not as an implementation detail. I've not seen a .NET Pub/Sub design, and would question it if I saw it.
4. LINQ Rx is quite interesting, but it in now way replaces .NET events.
So, I don't see .NET events going anywhere, and think saying "death to .NET events" is silly in the extreme. However, deeper thinking about this, your post is really about the evolution of higher level abstractions, and I can't totally fault that. I still think a lot of what was said was bunk, because these higher level abstractions are not only based on events, but they include the events in the public APIs in one form or another. Maybe, some day, there will be an abstraction that buries them entirely... but that day isn't coming any time soon, IMHO.
@wekempf - On #3 there are a few now. For everything else - yes, this is about higher abstractions, and in some cases using more appropriate abstractions.
My favorite replacement of events and/or traditional threads is the high-level concept of an operation queue in which one can set dependencies among queued operations and the queue implementation handles the details.
there are few errors as tricky as event handlers firing on disposed objects.
cheers.