Geek Answers Handbook

Benefits of events using EventArgs / EventArgs <T> delegate types instead of ...

I understand the benefits of events using signed delegate types delegate void delegate_name(object sender, EventArgs e)

a) But besides the fact that this can save us some typing, are there other reasons why we should use already defined types of delegates EventHandler/EventHandler<T>instead of declaring our own types of delegates with a signature delegate void delegate_name(object sender, EventArgs e)?

b) Two other reasons that I can think of for using the predefined types of delegates EventArgs/EventArgs<T>:

  • people consuming a particular event (say event EventHandler my_event) will immediately learn how to use this event?

  • perhaps some popular third-party methods accept delegate types as parameters EventHandler/ EventHandler<T>, and thus, if it is likely that our code can use these third-party methods, should we use predefined delegates EventHandler/EventHandler<T>?

Thank you

+5
source share
5 answers

For me, the question is a bit strange. What is the use of this otherwise (defining types of delegates that exactly match EventHandler<TEventArgs>for some TEventArgs)?

, , , "" : API EventHandler<TEventArgs>; , Rx Extensions , :

Observable.FromEvent<TEventArgs>(
    Action<EventHandler<TEventArgs>> addHandler,
    Action<EventHandler<TEventArgs>> removeHandler
);

, , EventHandler<TEventArgs>, , , ( , ).

+11

:

  • , - , , .
+7

:

  • (, ),
  • ( EventHandler

; , ( , , ).

+5

Pro # 2008 .NET 3.5:

, *, ** .... , event , , .

* += -=.

**... private, .

EventHandler, .

+2

- . EventArgs, , "MS , ", , EventArgs. ?

  • .NET-1.0ish, / .
  • , , EventArg , , . , , , .
  • , , - , object sender - ?!?!

, "" , . :

namespace MyAPI.Data.Delegates
{
    public delegate void DataEventHandler<TData>(DataFeed<TData> sender, TData data);
}

:

public event DataEventHandler<TData> DataReady = delegate { };

:

  • . , .
  • . object sender , , , .
  • new() , , . , , .
  • ___EventHandler , - , API , .

The only drawback is that it is difficult for users of your code to connect your event to existing methods that have a signature object sender, EventArgs e. However, this point is controversial, because if your event provides additional data (for example, you created your own subclass EventArgs), then they will have to change the signature of the method in any case (or apply to the type of your subclass). In any case, it's still nasty.

That is why I like my way.

+2
source

More articles:


All Articles