Friday, August 29, 2008

The Evolution of Delegates

In this post I'll discuss how delegates have evolved along with the evolution of .NET and C#. Specifically, how the introduction of anonymous methods and lambda expression helped make delegates more concise and useful.

This post is the first in a series of "Back-to-Basic" posts where I'll discuss basic .NET concepts and show how they have progressed with each new release of the .NET Framework.

I love delegates. If I had to come up with a list of my top 5 .NET features, delegates would definitely be high up on the list.

A Delegate, as defined by MSDN is:

"A type that defines a method signature, and can be associated with any method with a compatible signature. You can invoke (or call) the method through the delegate. Delegates are used to pass methods as arguments to other methods."

Delegates are first class citizens in the .NET framework and the C# language, and one of the fundamental types in the framework. They are used throughout the framework and enable important features such as events and asynchronous method calls.

In the old days, if we wanted a delegate that takes one parameter and returns void we had to declare one like this:

public delegate void DoWorkDelegate(string data);

Then we had to implement a method that conforms to the signature of the delegate:

private void DoSomeWork(string s)
{
// Do some work here
Console.WriteLine(s);
}

And finally, instantiate the delegate in our code:

DoWorkDelegate del = new DoWorkDelegate(DoSomeWork);

In .NET 2.0 we could use a simplified syntax to instantiate the delegate:

DoWorkDelegate del = DoSomeWork;

The introduction of Generics in .NET 2.0 introduces a generic delegate Action. Action encapsulates a delegate that returns void and accepts 0 to 4 parameters (there are actually 5 generic Action types defined: Action, Action<T>, Action<T1, T2>, Action<T1, T2, T3>, Action<T1, T2, T3, T4>). So in the above example, we could have saved us the trouble of defining our own custom delegate "DoWorkDelegate" and instead used this:

Action<string> del = DoSomeWork;

.NET 2.0 also introduced the concept of Anonymous Methods. This lets us avoid defining the "DoSomeWrok" method altogether and write it inline with the definition of the delegate:

Action<string> del = delegate(string s)
{
Console.WriteLine(s);
};

Finally, C# 3.0 introduced Lambda Expressions, which allow us to define the method inline like this:

Action<string> del = s =>
{
Console.WriteLine(s);
};

One more delegate worth mentioning is the Func delegate. Func was introduced in .NET 3.5 and just like its older brother, the Action, it encapsulates a delegate, but unlike Action Func encapsulates a delegate that takes 0 to 4 and returns a value. For example:

// Using Func we can replace this:
delegate int DoWorkDelegate(string data);

// with this:
Func<string, int> del;

In all the above samples (except for the last one) we end up with a "del" object. We could then use the "del" instance anywhere in our code to execute the "DoSomeWork" method. We could even pass "del" as an argument to other methods or objects that could also execute the same method:

// This is the verbose way:
del.Invoke("Do some work");

// This is a bit more concise
del("Do some work");

// This executes the method asynchronously
del.BeginInvoke("Do some work", null, null);

Next time on SapienCoder I will describe how to use delegates to implement Asynchronous programming patterns.

2 comments:

Guy Soffer September 10, 2008 10:43 PM  

Just started reading the post series. Good explanation.

murty March 10, 2009 6:49 PM  

The post is good and informative. I think giving some good and practical examples on how to use delegates in real time scenarios would make it more helpful.