What is the difference between delegate and event in C#?

Question

Possible Duplicate:
What is the difference between a delegate and events?

This question I got at an interview and I still don't know what the answer should be.
I would appreciate any thoughts!

Answer 1

I have an article on pretty much exactly

In brief, you can think of an event as being a bit like a property - but instead of having get/set operations, it has add/remove. The value being added/removed is always a delegate reference.

Delegates themselves support operations of:

• Combine (chain multiple delegate instances together)
• Remove (split them up again)
• Invoke (synchronous or asynchronous)
• Various things to do with finding out the target, invocation list etc

Note that delegates themselves are immutable, so combine/remove operations return a new delegate instance rather than modifying the existing ones.

Answer 2

The other answers so far are all quite good. Here's another way to think about it.

What's the semantic difference between a property and a field? I don't mean what are the technical differences, like a property is actually a pair of methods, blah blah blah. I mean, as far as understanding the meaning of a program goes, what is the difference?

A property is usually a public member of a class, and it represents a property of the thing being modelled. That is, you want to make a model of a newspaper so you make a class Newspaper and you give it a property Publisher. The publisher is a property of newspapers, so Publisher is a property of the Newspaper class.

A field is usually an implementation detail of a class. Maybe the Publisher property is actually implemented as a field. But newspapers do not have "fields", so you don't expose the publisher field as a public member of the Newspaper class; you use it as a private implementation detail of the Publisher property.

Events and delegates are somewhat analogous. An event is something in the model. A button is a thing that can inform you when it is clicked, so the Button class has a "Click" event. The delegate that actually does the informing is the implementation detail of the event.

Answer 3

Basically, a delegate is just a wrapper around what would be a function pointer in C (or a list of function pointers).

An event is an even higher level abstraction that wraps the concept of a delegate together with methods to subscribe and unsubscribe a method to such delegates.

An event is a “property” that exposes an add and remove method (invoked via += and -= in code) to add/remove subscribers to a delegate list.

Answer 4

A delegate is similar to a function pointer in C/C++. It holds a reference to a method and to an object instance (if the method is non-static). Delegates are usually multicast, i.e. they hold references to several object/method pairs.

An event is a notification mechanism, based on delegates. The only thing it exposes publicly is a pair of methods (add/remove) to subscribe to or unsubscribe from the notification. A delegate type is used to define the signature of the handler methods, and the list of subscribers are (usually) stored internally as a delegate.

Answer 5

I readily admit that this reply doesn't compare the difference between delegates and events. However, I think with the replies that others have given for Events along with a bit more detailed explanation on delegates, you will see the difference between the two. More specifically, once you have a clearer understanding of delegates, I think you will gain a conceptual difference between delegates and events.

What has helped me in understanding what a delegate is, is thinking of them as nothing more than a container for a single method.

To conceptualize how a delegate is a 'container' of a method, review this example that makes use of a delegate to invoke three different methods - Note that although the same delegate instance is used to invoke three different methods, the delegate instance will only contain (or target) one method at any given time.

class Program
{
    delegate void MyDelegate();

    static void Main()
    {            
        //Notice how we use the same delegate instance
        //to target different methods of the same signature

        MyDelegate myDelegate = new MyDelegate(MethodA);
        myDelegate(); //Invoke the method
        myDelegate = MethodB;
        myDelegate();
        myDelegate = MyClass.MethodZ;
        myDelegate();

        Console.ReadLine();
    }

    static void MethodA()
    {
        Console.WriteLine("Method 'A' is doing work.");
    }

    static void MethodB()
    {
        Console.WriteLine("Method 'B' is doing work.");
    }

    class MyClass
    {
        public static void MethodZ()
        {
            Console.WriteLine("Method 'Z' of MyClass is doing work");
        }
    }
}

You'll notice that the delegate in the example can contain/target any method that has the same signature as the delegate (returns void and takes zero parameters in our example). If you pause here and digest that principle, you're off to a good start at understanding delegates.

With that being said, what confused me about delegates is when I would ever explicitly implement delegates in my code. The example program above explicitly makes use of a delegate, but there is no practical reason to do so since the Main() method could just as well have called the target methods directly - i.e. we could have just done...

static void Main()
{
    MethodA();
    MethodB();
    MyClass.MethodZ();

    Console.ReadLine();
}

So what is an example of when we would implement a delegate explicitly? Jon Skeet helped me with answering that question when he said

...you can think of a delegate type as being a bit like an interface with a single method.

Knowing that a delegate is a container for a method and, now, considering that a delegate is like an Interface with a single method, consider this:

Say we have a program that will start the engines of different types of vehicles - Car, Motorcyle, and Airplane.

Our program will consist of vehicle classes - one class for each vehicle type. Each vehicle class is responsible for starting its own engine. In addition, similar to implementing an Interface, each class will make sure that its method that starts its own engine, will have a specified signature that all other classes (and the Main) agree upon.

So we have something like this:

class VehicleProgram
{
    //All vehicle classes implement their own engine starter method that has this signature
    delegate void StartEngine();
    static void Main()
    {
        //The Main doesn't know the details of starting an engine.
        //It delegates the responsibility to the concrete vehicle class
        foreach (StartEngine starter in GetVehicleStarters())
        {
            starter(); //Invoke the method
        }

        Console.ReadLine();
    }

    static List<StartEngine> GetVehicleStarters()
    {
        //Create a list of delegates that target the engine starter methods
        List<StartEngine> starters = new List<StartEngine>();

        starters.Add(Car.StartCar);
        starters.Add(Motorcycle.StartMotorcycle);
        starters.Add(Airplane.StartAirplane);

        return (starters);
    }

    class Car
    {
        public static void StartCar()
        {
            Console.WriteLine("The car is starting.");
        }
    }

    class Motorcycle
    {
        public static void StartMotorcycle()
        {
            Console.WriteLine("The motorcycle is starting.");
        }
    }

    class Airplane
    {
        public static void StartAirplane()
        {
            Console.WriteLine("The airplane is starting.");
        }
    }
}

Since delegates hold methods, we were able to implement a design where the Main() simply gets a list of delegates then invokes the method. This design is very similar to how we implement Interfaces.

Read more on When to Use Delegates Instead of Interfaces

Answer 6

Here's a really good article on it.

http://www.akadia.com/services/dotnet_delegates_and_events.html

Basically, events provide for a tightly coupled publish subscribe paradigm, while delegates provide for a much more loosely coupled design.

Events are easier and more straightforward to use, though.

Answer 7

Delegates are nothing but a function pointer, where in the function gets called asynchronously But Events are nothing but notification. For example clicking button is an event, so for that you need subscribe for the click event of a button etc..