Why .NET Events Suck

The .NET events are so common that almost nobody even thinks to consider practical alternatives to them. And that's a mistake. I'm going to show how much interfaces are better in OO sense.

Consider two simple implementations of a very common Listener scenario where one class is "listening" another for some useful events.

First, .NET event-based version:

And interface-based version:

The pros of the interface-based version are:

  • An instance of Worker always references to a not-null WorkListener, which is great point since the Listener is its Dependency.
  • ...and Worker claims about that as clear as possible - via its constructor. It's not possible to create a Worker without a valid instance of a class implementing WorkListener.
  • It's absolutely clear at a glance that AnotherClass plays WorkListener role. In the even-based version all we have is just a public method with a rather weird (in context of the rest class's public interface) name and semantic (Work's Done? What work? Who is call it? When?).
  • AnotherClass.WorkDone() is private which is a good thing - AnotherClass's public interface is not polluted with a method that's not a class's responsibility.
The only con I can see:
  • It's not multicasting. However, it's rarely the case when multicasting is really needed.


    Popular posts from this blog

    Computing cryptography hashes: Rust, F#, D and Scala

    Upcoming F# struct tuples: are they always faster?

    Composing custom error types in F#