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>意图明确。