IList是否真的是一个更好的数组替代品

Question

今天我读了Eric Lippert的一篇文章，其中描述了the harm of arrays。提到当我们需要一组值时，我们应该提供值，而不是指向值列表的变量。因此，Eric建议每当我们想要返回方法中的项集合时，我们应该返回IList<T>，它提供与数组相同的内容，即：

1. 启用索引访问
2. 启用迭代项目
3. 是强类型的

然而，与数组相比，该列表还提供了添加或删除项目的成员，从而修改了集合对象。我们当然可以将集合包装成ReadOnlyCollection并返回IEnumerable<T>，但之后我们将失去索引的可访问性。此外，调用者无法知道ReSharper警告“相同枚举的可能迭代”是否适用，因为他不知道内部枚举只是包含在ReadOnlyCollection内的列表。因此调用者不知道该集合是否已经实现。

所以我想要的是一个项目集合，其中集合本身是不可变的（但项目不必是，它们不会在IList上），这意味着我们无法添加/删除/插入项目到基础列表。然而，从我的API返回ReadOnlyCollection似乎很奇怪，至少我从未见过API这样做过。

因此阵列似乎完全符合我的需要，不是吗？

Answer 1

  

我们当然可以将集合包装成ReadOnlyCollection并返回IEnumerable<T>

为什么这样？ ReadOnlyCollection<T>实现了IList<T>，所以除非有更好的方法，否则声明返回类型IList<T>并返回ReadOnlyCollection<T>的实例似乎是一个很好的方法

但是，恰好在当前的.NET Framework版本中，有一种更好的方法：返回ReadOnlyCollection<T>的实例，但指定返回类型IReadOnlyList<T>。虽然IList<T>并未真正承诺允许调用者进行修改，但IReadOnlyList<T>明确表示意图。