2

I've been recently learning 'events' and 'delegates' in C#. Now I have a question that I didn't find the answer to, anywhere else.

As we all know every event is created based on a specific delegate. At first I thought that events are like delegate instances, but then I figured out that they are not.

My question here is that what is the relation between an event and its base delegate? does that event create an instance of the delegate and assign the 'event handler' methods to that at the runtime? or the assigned delegate is just a convention for assigning 'event handlers'?

Arad Alvand
  • 8,607
  • 10
  • 51
  • 71
  • Did you read this: https://stackoverflow.com/questions/563549/difference-between-events-and-delegates-and-its-respective-applications? – MakePeaceGreatAgain Mar 10 '18 at 15:44
  • event is basically two methods: `Add(DelegateType handler)` and `Remove(DelegateType handler`, which are invoked with `+=` and `-=` syntax. What happens inside those method depends on implementation of particular event. – Evk Mar 10 '18 at 16:22

3 Answers3

1

An event is basically a list of methods to be invoked. Thus, delegate is nothing but kind of "strongly-typed" method reference. That is why there are exactly 2 possible operations on events: add handler += and remove handler: -=. That should prevent mistakes like accidental .Clear(), which will unsubscribe all existing listeners momentarily.

If you need more "obvious" example of how it works, than let the List<Delegate> be an event, where Delegate represents reference to a whatever function of a certain signature. Whenever you need to "invoke" event, you loop over existing list of delegates and simply invoke each one with the same parameter.

Zazaeil
  • 3,900
  • 2
  • 14
  • 31
  • In fact, an event isn´t a list of delegates. A delegate has an invocation-list, which is a list of handlers. – MakePeaceGreatAgain Mar 10 '18 at 16:08
  • @HimBromBeere sure, but those are implantation details needed just to "make it work" with `.NET`. Those can vary from platform to platform. Since OP is about the **concept** of event rather than `.NET`-specific stuff, I omitted quite a lot of details. – Zazaeil Mar 10 '18 at 16:20
  • That´s how both events and delegate work. They are not bound to just *a single* handler. You can assign as many as you want. – MakePeaceGreatAgain Mar 10 '18 at 16:25
  • @HimBromBeere and yet still those are just implementation details, which can vary a lot. Those does not form an essence of the `event` as a programming technique. – Zazaeil Mar 10 '18 at 16:27
0

An event for a delegate is the same as aan auto-property for a backing-field. As an auto-property is just a wrapper around a backing-field an event is just a wrapper around a (backing) delegate. It provides an add- and a remove-method to append or remove event-handlers. So you have a private list of handlers and the event is just a wrapper to expose this list to the outside.

You can define an event as follows:

private EventHandler _explicitEvent;
public event EventHandler ExplicitEvent 
{
    add { _explicitEvent += value; } 
    remove { _explicitEvent -= value; }
}

So you have a private backing-field, which is a delegate. You can surely assign multiple handlers to the same delegate and thus to the event. In fact when you have an event as this:

public event EventHandler MyEvent;

the compiler will implicitely create the private backing-delegate for you, as it does for auto-properties also.

As for properties you can add some further logic within the add- and -remove-accessors in order to modify what happens when assigining an handler. You could make some validations for example or call some logging.

MakePeaceGreatAgain
  • 35,491
  • 6
  • 60
  • 111
  • @AmirHosseinAhmadi Can you elaborate on this? What do you mean? – MakePeaceGreatAgain Mar 10 '18 at 15:50
  • The other answer here is saying something completely different :) who should I believe? – Arad Alvand Mar 10 '18 at 15:57
  • Is it really right? because the other answer in this page has another different answer. @HimBromBeere – Arad Alvand Mar 10 '18 at 16:05
  • @AmirHosseinAhmadi Where is it "completely different"? The other answer just states that an event is a list of methods to be invoked, which is all fine. – MakePeaceGreatAgain Mar 10 '18 at 16:07
  • "The other answer" is not completely different. It just skips implementation details and focuses on the concept of what technically `event` is. Just in case one day you'll switch to, let say, `Haskell`, where no keyword `event`, nor any kind of explicit `delegate` even exist, you'll still be able to bring an events there. Which is not the case if you stick to unnecessary details like "backing field" or whatever language-specific else... – Zazaeil Mar 10 '18 at 16:24
  • A Delegate itself is really just a "strongly type function reference". In Native C++ you can do similar stuff with a simple old pointer. Events are in the end just Multicast Delegates (https://msdn.microsoft.com/en-us/library/system.multicastdelegate.aspx) with some Syntax sugar/automimplement accessors so you can not do the wrong things by accident (only add/remove) from outside the class. And Multicast Delegates are just Lists with some automatic itteration on invoking. – Christopher Mar 10 '18 at 17:42
0

According to Microsoft Docs => Here

An event is a special kind of multicast delegate that can only be invoked from within the class that it is declared in. Client code subscribes to the event by providing a reference to a method that should be invoked when the event is fired. These methods are added to the delegate's invocation list through event accessors.

So, the answer would be: Yes. Events are basically a special type of multicast delegate.

Arad Alvand
  • 8,607
  • 10
  • 51
  • 71