既然我们有了泛型,是否还需要 EventArg 类
对于泛型,是否有理由创建特定的派生 EventArg 类
现在您似乎可以简单地通过泛型实现即时使用它们。
我应该检查所有示例并删除我的 eventArg 类(StringEventArgs、MyFooEventArgs 等...)
public class EventArgs<T> : EventArgs
{
public EventArgs(T value)
{
m_value = value;
}
private T m_value;
public T Value
{
get { return m_value; }
}
}
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; }
}
}
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(4)
您所描述的本质上是 元组,用于特定目的的分组值。 它们是函数式编程中的有用构造,并且很好地支持这种风格。
缺点是它们的值没有命名,并且需要上下文才能理解。
EventArgs
就其本质而言,通常在远离相关上下文的情况下被使用。 因此,元组式的EventArgs
可能会让消费者感到非常困惑。假设我们有一个事件指示某些除法已经完成,并且它带有分子、分母和结果:
事件处理程序有一些歧义:
使用表示事件的
EventArgs
会更清楚:通用可重用
EventArgs
类简化了机制的开发,但牺牲了表达意图。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.请参阅 自定义通用 EventArgs 文章,作者:Matthew Cochran,在那篇文章中,他描述了如何进一步扩展它两个和三个成员。
使用泛型 EventArgs 有其用途,当然也有其误用,因为类型信息会在此过程中丢失。
在下面的示例中,它是类型安全的,但更多的是 LOC:
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:
我认为元组风格的 EventArgs 很有用。 就像 Tuple 一样,它们可能会被滥用,但看来我的懒惰比我的谨慎意识更强烈。 我实现了以下内容:
可以按如下方式使用(与事件引发程序扩展一起使用时)
I think Tuple-style EventArgs are useful. Just like Tuple's, they can be misused, but it seems my laziness is stronger than my sense of caution. I implemented the following:
Can be used as follows (when used with an event raiser extension)
正如 TcKs 已经说过的:如果您只需要传递一个值,请使用
EventArgs
,否则从EventArgs
派生(或EventArgs
, 任何你想要的)。As TcKs already said: Use
EventArgs<T>
if you only need to pass one value, otherwise derive fromEventArgs
(orEventArgs<T>
, whatever you want).