Question

我有一个当前定义没有事件参数的事件。也就是说，它发送的EventArgs是EventArgs.Empty。

在这种情况下，最简单的方法是将我的事件处理程序声明为：

EventHandler<System.EventArgs> MyCustomEvent;

我不打算在此事件中添加任何事件参数，但是将来可能需要更改任何代码。

因此，我倾向于让我的所有事件始终创建一个空事件args类型，其内容来自System.EventArgs，即使当前不需要事件args也是如此。像这样：

public class MyCustomEventArgs : EventArgs
{
}

然后我的事件定义变为以下内容：

EventHandler<MyCustomEventArgs> MyCustomEvent;

所以我的问题是：定义我自己的MyCustomEventArgs是否更好，即使它没有添加除System.EventArgs之外的任何内容，因此可以更容易地在将来添加事件参数？或者将事件明确定义为返回System.EventArgs是否更好，以便用户更清楚没有额外的事件参数？

我倾向于为我的所有事件创建自定义事件参数，即使事件参数为空。但我想知道是否有人认为让事件参数为空的用户更清楚会更好吗？

提前非常感谢，

麦克

Answer 1

Brad Abrams和Krzysztof Cwalina的Framework Design Guidelines：

考虑使用EventArgs的子类作为事件参数，除非您完全确定事件永远不需要携带任何数据到事件处理方法，在这种情况下您可以使用EventArgs直接输入。

如果直接使用EventArgs发送API，则无法在不破坏兼容性的情况下添加任何要携带的数据。如果使用子类，即使最初完全为空，也可以在需要时向子类添加属性。

就个人而言，我认为这归结为兼容性问题。如果你要让一个类库供别人使用，那么我会使用一个子类。如果您只在自己的代码中使用事件，那么（正如Alfred所说），YAGNI适用。当你从EventArgs更改为你自己的派生类时，这将是一个重大变化，但由于它只会破坏你自己的代码，所以这不是太大的问题。

Answer 2

YAGNI

我建议坚持使用EventArgs，只在你真正需要它时才使用另一种东西。

更新：

正如 adrianbanks 指出的那样，如果您的代码将被其他不受您控制的代码所使用（即您无法自行编译的代码）或者如果重新编译消费者代码会很麻烦，那么你应该使用 EventHandler＆lt; YourEventArgs＆gt; 。

如果没有参数的Event定义了自己的自定义EventArgs，或者只是使用System.EventArgs？

2 个答案: