12

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

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

EventHandler<System.EventArgs> MyCustomEvent;

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

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

public class MyCustomEventArgs : EventArgs
{
}

然后我的事件定义如下：

EventHandler<MyCustomEventArgs> MyCustomEvent;

所以我的问题是：定义我自己的是否更好MyCustomEventArgs，即使它除了继承之外没有添加任何东西System.EventArgs，以便将来可以更轻松地添加事件参数？或者最好将我的事件明确定义为返回System.EventArgs，以便用户更清楚没有额外的事件参数？

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

非常感谢提前，

麦克风

4

2 回答 2

14

来自Brad Abrams 和 Krzysztof Cwalina 的框架设计指南：

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

如果您直接使用 APIEventArgs发布，您将永远无法添加任何要随事件携带的数据而不会破坏兼容性。如果您使用子类，即使最初完全为空，您也可以在需要时向子类添加属性。

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

于 2009-08-23T14:03:31.250 回答
9

雅尼

我建议坚持使用 EventArgs，仅在您真正需要时才使用其他东西。

更新：

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

于 2009-08-23T13:32:14.927 回答