What’s the difference between Vent and Delegate?

Asked

Viewed 1,160 times

11

I see how it works delegate and event, but I saw no use of event. For example:

public delegate void ChangedEventHandler(object sender, BaseEventArgs e);
public ChangedEventHandler Changed;

The code above works like the one below:

public delegate void ChangedEventHandler(object sender, BaseEventArgs e);
public event ChangedEventHandler Changed;

If both work the same way, what is the use of event?

From what I understand (if I’m wrong, correct me) o event is a modifier that shows that he is instantiating a delegate which has as parameters a class derived from EventArgs and an Object? And that too event can be placed in interfaces?

1 answer

6


The event system is a much more powerful mechanism. It uses delegates as a basis but it does more than that. It is the implementation in the language of what is called Observer Pattern (example of implementation in C#).

Note that in the example shown in link above everything that needs to be done to have a running event needs to be done by the programmer. The command event tells the compiler that he must be part of this "dirty work" for you. Not that it’s too complicated, but it certainly takes more work and it’s easier to make mistakes when you have more to worry about.

Nothing stops you from implementing this design pattern on their own with delegates or even without them. But you will have to write all the code necessary for this. You’ll have to make sure he’s all right. You will have to write the entire mechanism that manages the registration and shutdown mechanisms of the event, in addition to the notification process.

The event abstract the mechanism. It is a concept at the highest level. In a certain way we can say that theme the same relation of the approached in that question.

A way to see what an event does is like this:

private ChangedEventHandler ChangedField;
public void AddChangedHandler(ChangedEventHandler handler) => this.ChangedField = (ChangedEventHandler)Delegate.Combine(this.Changed, handler);
public void RemoveChangedHandler(ChangedEventHandler handler) => this.ChangedField = (ChangedEventHandler)Delegate.Remove(this.Changed, handler);

I put in the Github for future reference.

The compiler implements this for you. And it’s not so simple to do it right because it implements it through a MulticastDelegate. Again, nothing prevents you from doing this and you might even need it if you need to do something more specific. It also gives more security by preventing certain operations from being done with delegates. Without its use, it is possible to raise an event externally, it is possible to replace an unduly delegate.

But his understanding is correct. Don’t expect too much magic from him. He doesn’t do anything that can’t be done without him in a "worse".

If you don’t care how easy it is, you should at least use it to make it clear semantically that you’re using an event and not just a delegate. It’s also a matter of intention. It is useful information for the programmer to better understand the code, allows the compiler to do something else and allows other components to interact with it more specifically, since he knows better what these delegates are being used for and how they were implemented.

Experimenta uses both forms and takes the CIL code generated by the compiler to see how it changes.

Not everyone knows that C# was born because of a Microsoft disagreement with Sun - creator of Java - because of this feature. At least that’s what the legend says. Lucky for us :)

Browser other questions tagged

You are not signed in. Login or sign up in order to post.