不好的做法：在界面中公开事件？

Question

在.net接口中公开事件被认为是不好的做法吗？

我发现很少有公开事件的.net框架接口。

由于

Answer 1

嗯，特别是有一个接口可能是.NET中最重要的接口之一，它暴露了一个事件...... INotifyPropertyChanged。 ：）

我从来没有看到任何来自FxCop或框架指南的建议，我看不出为什么会这样。唯一的问题是，如果你明确地实现了接口，那么实现事件就会变得很麻烦，因为你必须使用显式的添加/删除访问器。

Answer 2

对于它的价值，我不相信这是一个不好的做法。

这当然不常见，但（我怀疑）更多是因为缺乏需要或使用其他技术。

我在界面上使用了很好的效果。

注意：如果你想通过COM或WCF公开接口，那么事件可能是一个糟糕的选择，但这只是少数情况。

Answer 3

我认为没问题。它只是指定一个合同，特别是指定它会触发那种类型的事件。

我个人在一些内部接口中使用它，它确实有助于清理代码。如果你没有在界面中指定它，它将必须在具体的类中，并且你将被绑定到特定的实现。

Answer 4

接口中的事件有一些适当的用途。它们提供了一种指定对象“传出”接口的方法。

例如，IBindingList包含ListChanged事件。

一个重要的设计决策是将事件与其他方法一起包含在进入的界面中，还是将其放在单独的界面中。关键因素是方法与特定事件的紧密耦合程度。

Answer 5

我认为这主要是因为事件可以取代对接口的需求。

通常，接口将用于例如Java等语言的事件系统。在.NET中，如果您有一个可以使用单个方法订阅的事件，则很少需要整个类以及该方法。

我确信可能存在实现事件的接口存在的合法情况，但我认为事件是减少接口需求的一种方式，而不是用来组成接口的东西。

我绝对不会认为这是不好的做法。

Answer 6

当接口实际需要事件时，接口需要事件是完全合乎逻辑的！

Answer 7

我认为这根本不好！我定义了一个接口，以便我可以将我的主应用程序与我需要经常更新的组件分离，从而在运行时动态实例化和调用。为了传达关于组件做什么的状态，我在接口契约中定义了几个事件，以便主应用程序知道要订阅什么，并且组件准确地发布主应用程序需要的内容。