Code Climber: Delegates
Delegates
This post provides introductory information on using delegates. It is the first in a three or four part series that will cover:
- Delegates
- Anonymous Delegates
- Anonymous Delegates that use generics
- Lambdas.
The overall goal of the series is to explain lambdas. I have however, broken this post out as a separate stand-alone piece that should be of interest to anyone who wants to understand delegates.
Delegates and Events
Whether you know it or not, you have probably used delegates thousands of times in your programming career. If you have ever written any code in Delphi, VB or C# then, then you have almost certainly written event handlers. One drops a button on a form, double clicks on the button, and then writes some code to handle a button click event. As the following declaration shows, those kinds of events rely on delegates:
public delegate void EventHandler(object sender, EventArgs e);
The event itself is not a delegate. It uses a delegate and then adds some extra functionality of its own. If, however, you understand something about how to use an event, then you are well on your way to understanding delegates.
C# Delegates
If a delegate is closely related to an event, but it is not an event, then what is it? How do we define the word delegate?
If you are an experienced programmer, then I might help if I say that a delegate is a C# implementation of a method or function pointer. In C#, however, we don't usually work directly with pointers. Instead, delegates are classes. You can use and pass around this delegate class around much as you would a function pointer. Unlike a function pointer, however, delegates are classes and are therefore type safe.
If you don't understand function pointers, then you are still no closer to understanding delegates. So lets go back one step further and see if there is a simple way to explain delegates without talking about function pointers.
Delegates allow you to delegate a particular action or function in your program to another chunk of code. When you click on a button, the button delegates the handling of the event to an object in your form or dialog. The same thing happens with ordinary delegates. If you pass a delegate to a method as a parameter, then that method can execute a predefined task by calling the delegate. It can delegate the task to the delegate -- if you follow me.
Delegating an Action
So that I can come up with the simplest example possible, I'll now give you a somewhat tongue in cheek scenario in which one could choose to use delegates. Suppose I were working in a team with a programmer who shows a lot of promise, but who is still new to programming. Very new. He's a hard working, so I like to assign him tasks, but I don't want the task to be too complicated. This programmer has a hard time remembering the difference between the equality operator (==) and the assignment operator (=). As a result, I might say something like this to him: "I want you to write a method called PerformCalculation. In that method, when it comes time to figure out whether the result of your calculation is equal to the number nine, I want you to delegate that task to me. To help you out, I will pass in a delegate called IsNine that will perform the calculation to determine if the result is equal to nine. It will return true if a number is equal to nine, otherwise it will return false. Do you understand?"
Listing 1 is the finished program that my friend and I created.
Listing 1: A simple delegate. The formatting here makes it hard to blockcopy this code directly, but I will attach the project to this post.
1: using System;
2: using System.Collections.Generic;
3: using System.Text;
4:
5: namespace ConsoleDelegate
6: {
7: class Program
8: {
9: public delegate Boolean IsNineDelegate(int i);
10:
11: public Boolean IsNiner(int i)
12: {
13: return i == 9;
14: }
15:
16: public void ShowMe()
17: {
18: Boolean result = PerformCalculation(IsNiner, 3, 6);
19: Console.WriteLine(result);
20: }
21:
22: public Boolean PerformCalculation(IsNineDelegate isNine, int value1, int value2)
23: {
24: int result = value1 + value2;
25: return isNine(result);
26: }
27:
28: static void Main(string[] args)
29: {
30: Program program = new Program();
31: program.ShowMe();
32: }
33: }
34: }
The first step is to write a method that will calculate whether a number is equal to nine. On lines eleven through fourteen, in the method called IsNiner, I complete that task.
My next job is to pass that method into the PerformCalculation function that I'm asking my friend to write. That turns out to be a two step process:
- Declare the delegate type
- Pass in the delegate instance to the user.
On line 9 the delegate is declared and given the name IsNineDelegate. If you remove the word delegate from line 9 and replace it with an "r", you will see that it's signature exactly matches the declaration of the IsNiner method on line 11. In particular, it is a public method that returns a Boolean value and accepts an integer as a parameter.
Now look down on line 22. The first parameter to the PerformCalculation method is a delegate of type IsNineDelegate. This means that you can pass in a method of type IsNineDelegate to this method . Look back at line 18 and you will see that I do in fact pass in the IsNiner method as the first parameter to the PerformCalculation method. Then on line 25, the IsNine delegate is actually called.
Some Details
You now have enough information to write your own delegates. In this section I'll give you some additional information that is not absolutely necessary to know, but which you might find useful.
I've said that the signature of the delegate type and the delegate instance need to be the same. They must return the same type and pass in the same types as parameters. However, you don't have to give the variables in the parameters the same name. For instance, the following is still valid code:
1: public delegate Boolean IsNineDelegate(int value);
2:
3: public Boolean IsNiner(int i)
4: {
5: return i == 9;
6: }
7:
8: public void ShowMe()
9: {
10: Boolean result = PerformCalculation(IsNiner, 3, 6);
11: Console.WriteLine(result);
12: }
In this code the delegate type declares the formal parameter as int nine, but the delegate instance declares the corresponding formal parameter as int i. This is completely legal, and the code on line 10 will still compile and run smoothly with no warnings and no errors.
On line 10 above, I pass in IsNiner directly. The following code would also be valid:
1: public void ShowMe()
2: {
3: IsNineDelegate myDelegate = IsNiner;
4: Boolean result = PerformCalculation(myDelegate, 3, 6);
5: Console.WriteLine(result);
6: }
As you can see, I've declared an instance of the IsNiner delegate called myDelegate. In this case, it is really just so much wasted motion, but there are times when it is useful to do something like this. (Notice that you don't need to call new when creating an instance of the IsNineDelegate on line 3. That was necessary in .NET 1.1, but is not necessary any longer.)
Some Caveats
You now know enough about delegates to be dangerous. I have not, however, told you enough to make you an expert in this subject. For one thing, I've said little about the connection between the code that I've shown you above and events.
Events are indeed a kind of delegate, but the approach the subject from the opposite point of view. They also have some special properties.
We have passed in a delegate to the PerformCalculation method in order to provide a helper method as a service. Events take the opposite approach. They are the ones that provide the service to the caller. You pass in an event to a method, and then that method helps out the caller by executing the event at the appropriate time. By doing this, it notifies the call that an event has occurred.
By implementing the observer pattern (aka as the publish-subscribe pattern, you can use delegates as a kind of make-shift event system. However, most developers use events when they want that functionality.
When you start thinking about events, it is easy to imagine the case in which two methods or classes need to be notified when a particular event occurs. This functionality can be supported through something called a multicast delegate. All delegates are actually multicast delegates, but you don't need to know that in order to work with the code I've been showing you.
Finally, it is important to note that true events add some restrictions to what you can do with multicast delegates. Events are multicast delegates, but there are restrictions on how they can be created and when they can only be fired within certain scopes.
The point I'm trying to drive home here is that I have not told you all that you need to know be an expert on the subject of delegates. However, I have told you enough so that you can start using delegates in your own programs. Furthermore, I've taught you enough so that you have the background necessary to learn how to create anonymous delegates, which is a subject I will cover in another post.
I should probably also stress a point I made earlier, which is that C# delegates are really classes. If you use the ILDASM utility that ships with at least some versions of Visual Studio, you can look at the simple program found in listing one and find the following class declaration:
1: .class auto ansi sealed nested public IsNineDelegate
2: extends [mscorlib]System.MulticastDelegate
3: {
4: } // end of class IsNineDelegate
Notice that IsNineDelegate is a sealed public class, and that it extends System.MulticastDelegate. In other words, delegates are really classes. They look and act like function pointers, but underneath the hood they are really classes. For most developers, this fact is just a useless piece of trivia. If it has any importance, it is just to highlight the fact that C# delegates are type safe.
Summary
In this post I've covered the basic facts you need to know to use delegates. You have seen how to declare a delegate, how to create a delegate instance, and how to pass it to a method which can consume the delegate.
I also went to pains to inform you about the limits of this post. It tells you the basic facts you need to know about delegates if you want to understand anonymous delegates. If you understand anonymous delegates, then you can understand anonymous generic delegates. Once you understand anonymous generic delegates, then you can understand lambdas. That's where all this heading. if you understand what I have written here, then you are well on your way to understanding lambdas.
If you don't care anything at all about lambdas, then at least you now have the basic information necessary to write delegates. If you want advanced information on this subject, then you now know to go off looking for information on multicast delegates, and on how events differ from delegates. By adding the event keyword to a delegate, you restrict what you can do with a delegate in certain important ways that help prevent you from falling into devilish traps that event developers find particularly alluring.
Comments
Anonymous
January 16, 2007
You've been kicked (a good thing) - Trackback from DotNetKicks.comAnonymous
January 17, 2007
Excellent post. For some reason (maybe my lack of formal programming training) this is a tough concept for me to grasp. One issue I have with every tutorial on delegates is that they all use contrived examples and not code from an actual system/requirement. Being that I learn by example, I never know if I can use delegates because I've never seen an example that's even close to a requirement of the software I'm building.Anonymous
January 17, 2007
Excellent post. I like your posts so much I have you on my blogroll. Keep up the great work!Anonymous
January 18, 2007
The comment has been removedAnonymous
February 15, 2007
Yeah seriously I dont understand the point of delegates either. Why not just call it directly.Anonymous
March 20, 2007
This post is quite good but it might can confuse the beginners.. But good to really get started.. GKAnonymous
November 06, 2007
The reason not to call it directly is that the technique shown here gives you more flexibility. For instance, you can create other methods called IsFiver and IsSixer that have the same signature as IsNiner. You could then pass in them instead of IsNiner. As a result, you could change the behavior of PerformCalculation without changing its code. Here is an example, where PerformCalculation now tests for equivalency with five, even though its code is identical to what is shown above: using System; using System.Collections.Generic; using System.Text; namespace LambdaTest01 { class NineDelegate { public delegate Boolean IsNineDelegate(int i); public Boolean IsFiver(int i) { return i == 5; } public Boolean IsNiner(int i) { return i == 9; } public void ShowMe() { Boolean result = PerformCalculation(IsFiver, 2, 3); Console.WriteLine(result); } public Boolean PerformCalculation(IsNineDelegate isNine, int value1, int value2) { int result = value1 + value2; return isNine(result); } } }Anonymous
January 03, 2008
Very good post. I was having a hard time understanding delegates until I read this post. I think basically, it's a way to pass a method signature into another method. I'm wrote and example of a "maybe" practical example here: http://students.signalflare.ca/gary/blog/2008/01/so-i-was-trying-to-figure-out-delegates.html Bear with me, as I'm just getting a hold of delegates myself.Anonymous
February 07, 2008
A while ago Charlie Calvert did a great job explaining delegates here . Readers were asking for moreAnonymous
February 07, 2008
A while ago Charlie Calvert did a great job explaining delegates here . Readers were asking for moreAnonymous
May 12, 2008
I am still not clear why need to go for delegates when we can call the method directly. Can anyone throw more light on this issue.? Can anyone give a better and simpler explanation ?Anonymous
May 29, 2008
Excellent one for understanding delegates and kudos to 'GAP' for building up on multicasting... to summarise my understanding(pls bear with me..) essentially delegates can be used in situations where, during the design time it can be used as pointer for a method used in a Function and later we can keep building on new methods with same signature as delegates and keep calling newer methods through the already desgined Function, since anyway we're merely passing new method's address to the delegate parameter in Function. Excellent...thanks much..Anonymous
June 24, 2008
Still i did not understand the code.Could you give me some simple examples about delegates?Anonymous
July 18, 2008
Charlie, I liked the example . I actually understood the need for delegates when you answered one of the comments... thanks for the simple illustration