c# - 为什么泛型 ICollection 不在 .NET 4.5 中实现 IReadOnlyCollection？

Question

在 .NET 4.5/C# 5 中，IReadOnlyCollection<T>用 Count 声明属性:

public interface IReadOnlyCollection<out T> : IEnumerable<T>, IEnumerable
{
    int Count { get; }
}

我在想，这对 ICollection<T> 是否有意义？实现 IReadOnlyCollection<T>界面也是:

public interface ICollection<T> : IEnumerable<T>, IEnumerable, *IReadOnlyCollection<T>*

这意味着实现 ICollection<T> 的类会自动执行 IReadOnlyCollection<T> .这对我来说听起来很合理。

ICollection<T>抽象可以看作是 IReadOnlyCollection<T> 的扩展抽象。注意 List<T> ，例如，同时实现 ICollection<T>和 IReadOnlyCollection<T> .

然而，它并不是这样设计的。

我在这里错过了什么？为什么会选择当前的实现？

---

更新

我正在寻找一个使用面向对象的设计推理来解释原因的答案:

• 具体类，例如 List<T>同时实现 IReadOnlyCollection<T> 和 ICollection<T>

是一个比以下更好的设计:

• ICollection<T>实现 IReadOnlyCollection<T>直接

---

另请注意，这本质上与以下问题相同:

1. 为什么不 IList<T>实现 IReadOnlyList<T> ？
2. 为什么不 IDictionary<T>实现 IReadOnlyDictionary<T> ？

Answer 1

可能有几个原因。这里有一些:

• 巨大的向后兼容性问题

  你会怎么写ICollection<T>的定义？ ？这看起来很自然:

  interface ICollection<T> : IReadOnlyCollection<T>
  {
      int Count { get; }
  }
  

  但是它有一个问题，因为IReadOnlyCollection<T>还声明了一个 Count属性(编译器会在这里发出警告)。除了警告之外，保持原样(相当于编写 new int Count )允许实现者对两个 Count 有不同实现通过显式实现至少一个属性。如果两个实现决定返回不同的值，这可能会很“有趣”。搬起石头砸自己的脚不是 C# 的风格。

  好的，那怎么样:

  interface ICollection<T> : IReadOnlyCollection<T>
  {
      // Count is "inherited" from IReadOnlyCollection<T>
  }
  

  好吧，这破坏了决定实现 Count 的所有现有代码明确地:

  class UnluckyClass : ICollection<Foo>
  {
       int ICollection<Foo>.Count { ... } // compiler error!
  }
  

  因此，在我看来，这个问题没有很好的解决方案:要么破坏现有代码，要么对每个人 强加一个容易出错的实现。所以the only winning move is not to play .