Thursday, July 21, 2011

Introduction to Delegates in C#

What is a delegate? Most articles dive straight into the technical stuff, but I think it makes it easier to learn when you start by looking at the metaphor - I will dive right into the practical example straight afterwards.

So first of all, what makes the word 'delegate' such an apt keyword?

The Metaphor
According to Wikipedia, a delegate is a person who is similar to a representative, but "delegates differ from representatives because they receive and carry out instructions from the group that sends them, and, unlike representatives, are not expected to act independently."

Imagine a government department is employing two private companies to carry out litter collection across two districts. The government are responsible for preparing the contracts, and intend to use a standard template contract for both private companies. But the two private companies have different operating practices, and each want to tailor their respective contracts to suit their own particular needs.

They each send a delegate to meet the government and make amendments to their respective contracts. Each delegate is briefed by their respective companies before they leave, so that they know exactly what their instructions are. Each delegate arrives intending to do the same thing - amend a contract. But their instructions and boundaries on how they can do that are different - and are defined clearly by the respective senders.

I'll end the metaphor here, because I don't want to lock into one example. But having that sense of what a delegate is should make the rest of this article easier to read.

Declaring a Delegate Type
First, let's declare a publicly accessible delegate type:

//Declare a delegate type
public delegate void BookProcessingDelegate(Book b);

It is important at this stage to understand that what we have defined is not a delegate but a delegate type. Each instance we later instantiate of this type will be an actual delegate.

Delegates are usually declared not as class members, but as peers of classes or structs, i.e. at the same level. This is because declared delegate types are types in their own right. They can ofcourse, also be declared nested inside a class (just like a class can be declared nested inside a class).

In other words, a delegate is an example of a reference-type, and is stored on the heap and accessed via a pointer (see my article on types, the stack and the heap).

Instantiating and Assigning a Delegate Method
Having declared our delegate type, there are three things we need to do to make use of it:

  1. Define a method (write some instructions)
  2. Instantiate a delegate and assign the method to it (brief the delegate of our instructions)
  3. Send the delegate off to do business on our behalf

I'm going to use a variation of the 'classic' delegate example, and note that I've commented numerically the implementation of the bullet points above:

//Declare a delegate type
public delegate void BookProcessingDelegate(Book b);

public class Book
{
    public string title { get; set; }
}

public class BookDB
{
    private IList<Book> books;

    public void ProcessBooks(BookProcessingDelegate del)
    {
        foreach(Book b in books)
        {
            // Call the delegate method
            del(b);
        }
    }
}

class Program
{
    //1. Define a method
    private static void PrintBookTitle(Book b)
    {
        Console.WriteLine(b.title);
    }

    static void Main()
    {
        BookDB bookDb = new BookDB();

        //2. Instantiate a delegate, and assign the method
        BookProcessingDelegate printTitles = PrintBookTitle;

        //3. Send the delegate off to do work on our behalf
        bookDb.ProcessBooks(printTitles);    
    }
}

When we assign the method to the delegate (item 2 above), we are actually assigning to the delegate a pointer to the method. Then, when the BookDB.ProcessBooks method uses (invokes) the delegate, it follows the pointer and actually invokes the referenced method.

Logically, it is exactly the same as if the body of the referenced method had been declared inside of BookDB. But ofcourse it wasn't, and that's the key to the usefulness of delegates - i'll discuss this in more detail shortly.

But first of all let's explore two more ideas - anonymous delegates, and multicast delegates.

Anonymous Delegates
In the above example, we assigned a named method which was a private class member (namely PrintBookTitle). If that method is only going to be used for this one specific purpose, it can be much more convenient to declare an anonymous method.

What follows is exactly the same code block as above, but now the PrintBookTitle method has been anonymised, causing steps 1 and 2 to become one statement:

class Program
{
    static void Main()
    {
        BookDB bookDb = new BookDB();

        //1. Define a method AND
        //2. Instantiate a delegate, and assign a method
        BookProcessingDelegate printTitles = delegate(Book b) {
            Console.WriteLine(b.title);
        };

        //3. Send the delegate off to do work on our behalf
        bookDb.ProcessBooks(printTitles);    
    }
}

Anonymous delegates are more concise, and they are the foundation of lambda expressions, which I discuss in another article.

Multicast Delegates
It's another odd word, but multicast is based on another metaphor. Check out the link to get a quick sense of that, but it's simple enough anyway. You can assign more than one method to a delegate. The delegate will respond when invoked, by executing each method in order:

class Program
{
    private static void PrintLower(Book b) {
        Console.WriteLine(b.title.ToLower());
    }

    private static void PrintUpper(Book b) {
        Console.WriteLine(b.title.ToUpper());
    }

    static void Main()
    {
        //Instantiate a delegate, and assign TWO methods
        BookProcessingDelegate printTitles = PrintUpper;
        printTitles += PrintLower;

        //You can also use the -= operator to remove methods
        //from the 'invocation list'
        printTitles -= PrintLower;
    }
}

You can add and remove methods to your heart's content. The resulting list of methods which must be called on invocation of the delegate is referred to as the delegate's invocation list.

If the delegate has a return value, only the value returned by the last method in the invocation list will be returned. Similarly, if the delegate has an out or ref parameter, the parameter will end up being equal to the value assigned in the last method in the invocation list (see also my article on parameter passing in C#).

What Are Delegates Useful For?
As we have seen, delegates give us the ability to assign functionality at runtime. This adds to our toolbox of assignment operations - we all know how easy it is to assign values, or references to objects. Now we can assign functionality too.

Look back to the first, main code-block of this article. It should be clear that any class, anywhere in your application that chooses to call BookDB.ProcessBooks can do so and provide it's own specific, tailored functionality. The Program class happens to have sent one particular type of functionality (printing to the console), but any delegate can point to any method implementation.

Without delegates, the creators of the BookDB class would have to have thought up in advance every possible thing that callers might want to do with the Book list - and provide lots of methods to cover all those bases. In doing so, the BookDB class would be taking on responsibilities that are not within it's problem domain.

The other way to achieve the same functionality without delegates would be for the BookDB to expose it's internal list as a property, or via an access method. The Program class could then iterate over the collection itself. But this approach would mean that the Program class was shouldering responsibilities that are not within it's domain - iterating over a collection.

Delegates therefore provide an elegant solution which helps achieve the Seperation of Concerns principle within your application architecture.

A Common Usage - Ad-Hoc Searching
There are lots of places in the .NET Framework where you can use delegates, and their newer equivalent, lambda expressions. We'll take a look at one example, by altering our BookDB code a little. Let's say you want to find a book with a particular title, from a list of Book items:

class AdHocSearch
{
    static void Main()
    {
        List<Book> bookDb = new List<Book>();
        bookDb.Add(new Book() { title="Romancing the Stone" });
        bookDb.Add(new Book() { title="Wuthering Heights" });

        Book foundBook = bookDb.Find(delegate(Book candidate)
        {
            return candidate.title.Equals("Wuthering Heights");
        });

        Console.WriteLine(foundBook.title);
    }
}

If you couldn't use a delegate, you would have to manually iterate over the list. But fortunately for us, the List<T>.Find() method will accept a delegate function which describes how to apply a condition which determines a match for us. This leaves the job of iterating the collection, with it's associated efficiency concerns, in the correct problem domain - the domain of the List.

Quick Runthrough
For a nice, quick, concise primer on the subjects I've discussed above, check out this Youtube video:

I don't think it stands up as a learning resource in it's own right, but as a primer it's quite well organised.

Further Reading
This is quite a nice delegates tutorial on MSDN.

No comments:

Post a Comment

Note: Only a member of this blog may post a comment.