What are the benefits of having Net compliant events?

Question

I understand how to use events in accordance with the principles of the Net Framework, but what are the advantages of using this template?

http://msdn.microsoft.com/en-us/library/aa645739%28VS.71%29.aspx :

The .NET Framework recommendations indicate that the delegate type used for an event should take two parameters, an "object source" parameter indicating the source of the event, and an "e" parameter that encapsulates any additional information about the event. The type parameter "e" should be inferred from the EventArgs class. For events that do not use any additional information, the .NET Framework already has an appropriate delegate type defined: EventHandler.

a) I see some advantages when using the value "source of the object" as the first parameter, since there are situations when several objects can have their own events for the same method. Thus, if, for example, we have 10 objects, and if all 10 objects set their events in the event handler M, then inside M we can use the value of the "object sender" parameter to identify the initiator of the event call.

• But as far as I can tell, the parameter "source of the object" is useful only if an event has occurred in the instance method. Thus, if the event occurred inside the static method, the parameter "source of the object" is useless ?!

b) Are there other benefits to using events in accordance with Net Framework guidelines?

c) Whatever the benefits, why should they get rid of the problems so that

• write additional code to put the necessary arguments into the object obtained from EventArgs
• to write additional code inside event handlers to extract information from an object obtained from EventArgs?

Thank you

Answer 1

As far as I can see, there are two main advantages:

• People writing code consuming an event will recognize the pattern and immediately learn how to use the event.
• The event signature is created in such a way that it is resistant to change.

The first point should be pretty obvious, without a lot of development.

As for the second point, there are two reasons for this (in my opinion). First, since the sender is an object , an event signature can be reused by several types. Secondly, since the second parameter is an EventArgs decendant, when you enter your own EventArgs class, this class can be extended later without changing the event signature.

Update
Answer to the questions:

I'm not sure what you mean by "the possibility of extending EventArgs without changing the signature of the event" ?!

Take an example, take the following class:

 public class SomeClass { public event EventHandler<FileEventArgs> SomethingHappened; } public class FileEventArgs : EventArgs { public FileEventArgs(string filename) { Filename = filename; } public string Filename { get; private set; } } 

Then we have a consumer that listens to the SomethingHappened event:

 static void SomethingHappenedHandler(object sender, FileEventArgs e) { // do something intelligent } 

Now let's say that we want to expand the information that we transmit in the case of information about what happened to the file:

 public enum WhatHappened { Copy, Rename, Delete } public class FileEventArgs : EventArgs { public FileEventArgs(string filename, WhatHappened whatHappened) { Filename = filename; WhatHappened = whatHappened; } public string Filename { get; private set; } public WhatHappened WhatHappened { get; private set; } } 

Now, if we decide to send the file name as a parameter in the event itself, we will need to change the signature of the event by adding another parameter, effectively breaking all the code that listens for the event. But since in the code above we simply added another property to the FileEventArgs class, the signature remains unchanged, and no listener should be updated (unless they want to use the newly added property, that is).

I write, assuming that if an event occurs inside a static method, then the parameter "source of the object" does not matter to use ?!

Yes, that's right. I usually pass null as the sender argument from static events (which, frankly, is very rare).

Answer 2

If you adhere to the principles of the .NET Framework, not just for events, but for everything, someone who needs to read your code or use your library will recognize it, which will make it easier for him. This is always good, as you should write code for your readers, not for your convenience. The good thing with .NET is that from the very beginning there are several standard recommendations, unlike thousands of conventions for C ++, etc., And most people know and apply this.

An added benefit of the standard event handler signature is that you can assign less specialized event handlers (e.g., EventHandler ) to a more specialized type of event, making it easier to develop if someone needs more data. It also makes it easy to add event handlers through Reflection, which can be useful in certain circumstances (for example, for the browser hierarchy of objects for some object model). I can assure you that the code for handling any event through Reflection is a complicated thing, which I decided by emitting IL code for each event, which I will always consider as a last resort.

As Fredrik Murk wrote at the same time, this makes it easier to extend your event later by adding parameters only to your EventArgs-derived class, and not to every event handler.

Answer 3

Well, one of the main advantages of the standard approach is the fact that he does what he says on tin. The standard approach means that any developer viewing your code immediately gets what is happening and how to use your events.

Answer 4

personally, I do not always adhere to this recommendation, only for work to be published for general reuse.

why?

• because I don’t always need to know the sender of the event.
• because moving delegate arguments - especially when there is only one - is for a separate overkill class

Yes, I know, the arguments may change in the future. But LAMBs. And, frankly, when I need to change the arguments in the event deletion, the compiler conveniently tells me all the places that used it, so I can check whether they handle the new parameters correctly. If I followed the standard and used my own EventArgs class, I would have to look for these places manually.

therefore, as usual, “it depends” and “use your own opinion” is applicable :-)

Answer 5

You can use the Generic Event Handler delegate (EventHandler <TEventArgs>) if you use standard event signatures and your event arguments are inherited from eventargs.

 public event EventHandler<MyCustomEventArgs> MyEvent; 

http://msdn.microsoft.com/en-us/library/db0etb8x.aspx