With generics, is there ever a reason to create specific derived EventArg classes
It seems like now you can simply use them on the fly with a generic implementation.
Should i go thorugh all of my examples and remove my eventArg classes (StringEventArgs, MyFooEventArgs, etc . .)
public class EventArgs<T> : EventArgs
{
public EventArgs(T value)
{
m_value = value;
}
private T m_value;
public T Value
{
get { return m_value; }
}
}
As TcKs already said: Use
EventArgs<T>
if you only need to pass one value, otherwise derive fromEventArgs
(orEventArgs<T>
, whatever you want).Look at the Custom Generic EventArgs article written by Matthew Cochran, in that article he describes how to expand it even further with two and three members.
Using generic EventArgs have their uses, and of course their misuses, as type information is lost in the process.
In the following example it is type-safe, but a bit more LOC:
What you are describing are essentially tuples, grouped values used for a particular purpose. They are a useful construct in functional programming and support that style very well.
The downside is that their values are not named, and they require context to be understood.
EventArgs
by their very nature are often consumed far away from their relevant context. Therefore, tuple-esqueEventArgs
can be very confusing for the consumer.Let's say we have an event indicating some division has been completed, and it carries the numerator, denominator, and result:
The event handler has some ambiguity:
This would be much clearer with an
EventArgs
representing the event:Generic reusable
EventArgs
classes ease development of the mechanism at the expense of expressing intent.I think Tuple-style EventArgs are useful. Just like Tuple's, they can be misused, but it seems my laziness is stronger that my sense of caution. I implemented the following:
Can be used as follows (when used with an event raiser extension)