Why does trying to understand delegates feel like trying to understand the nature of the universe?

I've read two books, tons of examples. They still make next to no sense to me. I could probably write some code that uses delegates, but I have no idea why. Am I the only one with this problem, or am I just an idiot? If anyone can actually explain to me when, where, and why I would actually use a delegate, I'll love you forever.

Delegates are just a way to pass around a function in a variable.

You pass a delegated function to do a callback. Such as when doing asynchronous IO, you pass a delegated function (a function you have written with the delegate parameter) that will be called when the data has been read off the disk.

As other people have mentioned delegates are handy for callbacks. They're useful for a whole load of other things too. For example in a game I've been working on recently bullets do different things when they hit (some do damage, some actually increase the health of the person they hit, some do no damage but poison the target and so on). The classical OOP way to do this would be a base bullet class and a load of subclasses

Bullet
    DamageBullet
    HealBullet
    PoisonBullet
    DoSomethingElseBullet
    PoisonAndThenHealBullet
    FooAndBarBullet
    ....

With this pattern, I have to define a new subclass every time I want some new behavior in a bullet, which is a mess and leads to a lot of duplicated code. Instead I solved it with delegates. A bullet has an OnHit delegate, which is called when the bullet hits an object, and of course I can make that delegate anything I like. So now I can create bullets like this

new Bullet(DamageDelegate)

Which obviously is a much nicer way of doing things.

In functional languages, you tend to see a lot more of this kind of thing.

A delegate is a simple container that knows where in the machine's memory a specific method is located.

All delegates have an Invoke(...) method, thus when someone has a delegate, he can actually execute it, without really having to know or bother what that method actually does.

This is especially helpful for decoupling stuff. GUI frameworks wouldn't be possible without that concept, because a Button simply can't know anything about your program you're going to use it in, so it can't call your methods by itself whenever it is clicked. Instead, you must tell it which methods it should call when it is clicked.

I guess you're familiar with events and you do use them regularly. An event field is actually a list of such delegates (also called a multi-cast delegate). Maybe things will become clearer when we look at how we could "simulate" events in C# if it didn't have the event keyword, but only (non-multicast) delegates:

public class Button : Rectangle
{
    private List<Delegate> _delegatesToNotifyForClick = new List<Delegate>();

    public void PleaseNotifyMeWhenClicked(Delegate d)
    {
        this._delegatesToNotifyForClick.Add(d);
    }

    // ...

    protected void GuiEngineToldMeSomeoneClickedMouseButtonInsideOfMyRectangle()
    {
        foreach (Delegate d in this._delegatesToNotifyForClick)
        {
            d.Invoke(this, this._someArgument);
        }
    }
}

// Then use that button in your form

public class MyForm : Form
{
    public MyForm()
    {
        Button myButton = new Button();
        myButton.PleaseNotifyMeWhenClicked(new Delegate(this.ShowMessage));
    }

    private void ShowMessage()
    {
        MessageBox.Show("I know that the button was clicked! :))))");
    }
 }
       

Hope I could help a little. ;-)

Maybe this helps:

• A delegate is a type (defining a method signature)
• A delegate instance is a reference to a method (AKA function pointer)
• A callback is a parameter of a delegate-type
• An event is a (kind of) property of a delegate-type

The purpose of delegates is that you can have variables/fields/parameters/properties(events) that 'hold' a function. That lets you store/pass a specific function you select runtime. Without it, every function call has to be fixed at compile time.

The syntax involving delegates (or events) can be a bit daunting at first, this has 2 reasons:

1. simple pointer-to-functions like in C/C++ would not be type-safe, in .NET the compiler actually generates a class around it, and then tries to hide that as much as possible.

2. delegates are the corner-stone of LINQ, and there is a steep evolution from the specify-everything in C#1 through anonymous methods (C#2) to lambdas (C#3).

Just get acquainted with 1 or 2 standard patterns.

Come on Guys! All of you successfully complicated the DELEGATES :)!

I will try to leave a hint here : i understood delegates once I realized jquery ajax calls in Javascript. for ex: ajax.send(url, data, successcallback, failcallback) is the signature of the function. as you know, it sends data to the server URL, as a response, It might be 200OK or some other error. In case of any such event(success/fail), you want to execute a function. So, this acts like a placeholder of a function, to be able to mention in either success or failure. That placeholder may not be very generic - it might accept a set of parameters and may/may not return value. That declaration of such Placeholder, if done in C# IS CALLED DELEGATE! As javascript functions not strict with number of arguments, you would just see them as GENERIC placeholders...but C# has some STRICT declarations... that boils down to DELEGATE declarations!!

Hope it helps!

Delegate is a type safe function pointer, meaning delegate points to a function when you invoke the delegate function the actual function will be invoked. It is mainly used when developing core application framework. When we want to decouple logic then we can use delegate. Ie instead of hand coding logic in a particular method we can pass the delegate to the function and set different function logic inside the delegate function. Delegates adds flexibility to your framework.

Example: how to use it

class Program
{
    public static void Main()
    {
        List<Employee> empList = new List<Employee>() {
           new Employee () {Name = "Test1", Experience = 6 },
           new Employee () {Name = "Test2", Experience = 2 },
          };

        // delegate point to the actual function
        IsPromotable isEligibleToPromote = new IsPromotable(IsEligibleToPromoteEmployee);
        Employee emp = new Employee();

        // pass the delegate to a method where the delegate will be invoked.
        emp.PromoteEmployee(empList, isEligibleToPromote);

        // same can be achieved using lambda empression no need to declare delegate 
        emp.PromoteEmployee(empList, emply => emply.Experience > 2);

        Console.ReadKey();
    }

    // this condition can change at calling end 
    public static bool IsEligibleToPromoteEmployee(Employee emp)
    {
        if (emp.Experience > 5)
            return true;
        else
            return false;
    }
}


public delegate bool IsPromotable(Employee emp);
public class Employee
{
    public string Name { get; set; }
    public int Experience { get; set; }

    // conditions changes it can 5, 6 years to promote
    public void PromoteEmployee(List<Employee> employees, IsPromotable isEligibleToPromote)
    {
        foreach (var employee in employees)
        {
            // invoke actual function
            if (isEligibleToPromote(employee))
            {
                Console.WriteLine("Promoted");
            }
        }
    }
}