Juri Strumpflohner
Juri Strumpflohner Juri is a full stack developer and tech lead with a special passion for the web and frontend development. He creates online videos for Egghead.io, writes articles on his blog and for tech magazines, speaks at conferences and holds training workshops. Juri is also a recognized Google Developer Expert in Web Technologies

Are anonymous Lambda style event handlers a readability killer?

3 min read

A standard event handling method in C# looks something like this
public void SomeOtherMethod()
{
MyClass aObj = new MyClass();
aObj.MyCustomEventName += new EventHandler(OnMyCustomEventName);
...
}

private void OnMyCustomEventName(object sender, EventArgs e)
{
//do what you need to
}
Pretty straightforward. Now since C# 3.0 you have the possibility to declare anonymous methods of the type
public void SomeOtherMethod()
{
MyClass aObj = new MyClass();
aObj.MyCustomEventName += delegate(Object sender, EventArgs e)
{
//do what you need to
};
}
This makes it more concise since you define the event handling code directly at the point where you register the event.
This is, by the way, also possible in Java by declaring anonymous types such as
public void someOtherMethod(){
...
MyClass aObj = new MyClass();
aObj.setOnMyCustomEventListener(new IMyCustomEventListener(){

public void onMyCustomEvent(...){
//do what you need to
}

});
}
Note:IMyCustomEventListener is an interface and nevertheless we use the new to "instantiate" it. How's that possible? Well, this is a language feature which behind instantiates an anonymous object implementing the according interface.

It is very similar to the C# declaration of the event by using anonymous methods. Now, Lambda expression allow you to write this even more concisely
public void SomeOtherMethod()
{
MyClass aObj = new MyClass();
aObj.MyCustomEventName += (s,e) =>
{
//do what you need to
};
}
Nice, isn't it? In this way defining an event is really fast. The only doubt I have is in terms of readability. Now clearly the example above is perfectly readable, but it is just a dummy example. But consider a method where you have to define lots of event handlers for different components. Then declaring all the handlers in the way above may soon get very smelly.
Note, beside others, one reason for applying Extract Method is for readability purposes. When reading over a method, your eyes should grasp the essence and you should be immediately able to tell what the method is about, although you may not know in detail what - for instance - the internally called method RetrieveExpiredItems(aProductBag) will do, but according to its name it will retrieve the expired items from an object called aProductBag and that may be enough because actually you may be interested in something completely different. On the other side, if you code everything in one method you may have substantial difficulties in finding the interesting piece because you're flooded with all the details you won't even care about.

This same principle may also apply to the "inline" definition of such event handlers using Lambda expressions. As long as they're simple "one-liners" it may not pose any major problem, but as soon as the code within these handlers starts to grow it may become problematic.
Questions? Thoughts? Hit me up on Twitter
comments powered by Disqus