c# - IList 真的是数组更好的替代品吗？

Question

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

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

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

所以我想要的是一个项目集合，其中集合本身是不可变的(但是这些项目不一定是，它们也不在 IList 上)，这意味着我们不能添加/删除/将项目插入基础列表。然而，我返回 ReadOnlyCollection 似乎很奇怪从我的 API 来看，至少我从未见过这样做的 API。

因此数组似乎非常适合我的需要，不是吗？

Answer 1

We could of course wrap the collection into a ReadOnlyCollection and return an IEnumerable<T>

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

然而，碰巧在当前的 .NET Framework 版本中，有一种稍微好一点的方法:返回一个 ReadOnlyCollection<T> 的实例。 , 但指定返回类型 IReadOnlyList<T> .同时 IList<T>并没有真正 promise 允许调用者进行修改，IReadOnlyList<T>明确说明了意图。