c# - 为实现 INotifyCollectionChanged 的​​集合返回 IEnumerable 是一种好习惯吗

Question

为 SO 写另一个问题时，我想到了一个我经常使用但从未真正反射(reflection)过的模式。但是现在，我不再确定这是不是正确的方法:

如果我有我的 WPF 控件将绑定(bind)到的集合，我几乎总是返回 IEnumerable<SomeType> .然而在内部，这在大多数情况下是一个 ReadOnlyObservableCollection<SomeType> .我从来没有遇到过这个问题，所有消费控件总是正确更新，这并不令人惊讶，因为它们会检查 INotifyCollectionChanged -界面。

但我现在的问题是，如果只在签名中声明 IEnumerable<SomeType> 是不好的做法但返回(也依赖于)更强大的东西(INotifyCollectionChanged)。

更新:

我试着澄清一下:

我的主要目的是返回一个 IEnumerable<SomeType> .但大多数时候，返回的 IEnumerable<SomeType>工具也 INotifyCollectionChanged例如 ReadOnlyObservableCollection<SomeType>做。消费控件相应地绑定(bind)(我的第二个意图是什么)。

也许我应该问:是否有一个接口(interface)恰好包含 IEnumerable 和 INotifyPropertyChanged。

Answer 1

记住，IEnumerable<T>和 INotifyCollectionChanged都是接口(interface)——它们不是确定的类型。您可以设计您的具体类来实现这两者，没有任何问题。您的 API 可以为方法调用返回适当的接口(interface)。事实上，这是一个很好的设计 - 无法避免。

ObservableCollection<T> 这样做(间接通过 Collection<T> )，并且还实现了 IList<T>以及其他接口(interface)。

如果您正在制作自己的自定义集合，并计划将其与数据绑定(bind)一起使用，我会让它实现 IEnumerable<T> (或者可能是 IList<T> ，如果合适的话)和 INotifyCollectionChanged .这将为它提供最佳的可用性，无论是代码还是高效绑定(bind)。

---

(and also depend on)

但是，依赖于不属于 API 一部分的接口(interface)是一种不好的做法。这是危险的，返回接口(interface)而不是具体类型的部分原因是允许稍后更改实现。通过对未声明的接口(interface)施加依赖，您会使代码变得脆弱。

话虽这么说，我经常做你正在尝试的事情，但这不是“硬”依赖。相反，我使用 IEnumerable<T> ，并检查 INotifyCollectionChanged - 如果它被实现，就利用它。但是，如果“辅助”接口(interface)不存在，我确实允许代码工作。