没有参数的事件应该定义自己的自定义EventArgs还是简单地使用System.EventArgs？
我有一个当前定义的事件，没有事件参数。也就是说，它发送的EventArgs是EventArgs.Empty。
在这种情况下，最简单的方法是将我的事件处理程序声明为：
EventHandler<System.EventArgs> MyCustomEvent;
我不打算向此事件添加任何事件参数，但将来可能需要更改任何代码。
因此，我倾向于让所有事件始终创建一个继承自 System.EventArgs 的空事件参数类型，即使当前不需要事件参数也是如此。像这样：
public class MyCustomEventArgs : EventArgs
{
}
然后我的事件定义如下：
EventHandler<MyCustomEventArgs> MyCustomEvent;
所以我的问题是：定义我自己的 MyCustomEventArgs 是否更好，即使它除了继承自 System.EventArgs 之外没有添加任何内容。 EventArgs，以便将来可以更轻松地添加事件参数？或者将我的事件显式定义为返回 System.EventArgs 是否更好，以便用户更清楚没有额外的事件参数？
我倾向于为所有事件创建自定义事件参数，即使事件参数为空。但我想知道其他人是否认为让用户更清楚事件参数为空会更好？
预先非常感谢，
迈克
I have an event that is currently defined with no event arguments. That is, the EventArgs it sends is EventArgs.Empty.
In this case, it is simplest to declare my Event handler as:
EventHandler<System.EventArgs> MyCustomEvent;
I do not plan on adding any event arguments to this event, but it is possible that any code could need to change in the future.
Therefore, I am leaning towards having all my events always create an empty event args type that inheretis from System.EventArgs, even if there are no event args currently needed. Something like this:
public class MyCustomEventArgs : EventArgs
{
}
And then my event definition becomes the following:
EventHandler<MyCustomEventArgs> MyCustomEvent;
So my question is this: is it better to define my own MyCustomEventArgs, even if it does not add anything beyond inheriting from System.EventArgs, so that event arguments could be added in the future more easily? Or is it better to explicitly define my event as returning System.EventArgs, so that it is clearer to the user that there are no extra event args?
I am leaning towards creating custom event arguments for all my events, even if the event arguments are empty. But I was wondering if others thought that making it clearer to the user that the event arguments are empty would be better?
Much thanks in advance,
Mike
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
来自 Brad Abrams 和 Krzysztof Cwalina 的框架设计指南：
就我个人而言，我认为这归结为兼容性问题。如果您正在制作一个供其他人使用的类库，那么我会使用子类。如果您只在自己的代码中使用事件，那么（正如 Alfred 所说），YAGNI 适用。当您从
EventArgs更改为您自己的派生类时，这将是一个重大更改，但由于它只会破坏您自己的代码，所以并不是什么大问题。From Framework Design Guidelines by Brad Abrams and Krzysztof Cwalina:
Personally, I think this comes down to the compatibility issue. If you are making a class library to be consumed by others, then I would use a subclass. If you are only using the events in your own code, then (as Alfred has said), YAGNI applies. It would be a breaking change when you change from
EventArgsto your own derived class, but since it would only break your own code it is not too much of a problem.YAGNI
我建议坚持使用 EventArgs，并且仅在您真正需要时才使用其他东西它。
更新：
正如adrianbanks指出的，如果您的代码将被不受您控制的其他代码（即您无法自己编译的代码）使用或者如果重新编译消费者代码会很麻烦，那么您应该使用EventHandler
YAGNI
I suggest to stick with EventArgs and only use another thing when you really become to need it.
UPDATE:
As adrianbanks pointed out, if your code is going to be consumed by other code that is not under your control (i.e. code that you cannot compile yourself) or if recompiling consumer code will be a hassle, then you should use EventHandler<YourEventArgs>.