为什么使用 ICollection<t> 在 IList<t> ?</t></t>

Question

我读过文章说如果您想要IEnumerable<T>的功能，但也想要Count属性，请使用ICollection<T> 。

但是，由于System.Linq.Enumerable中的扩展方法提供了诸如ElementAt()之类的方法，为什么不直接使用IList<T> ，因为它使用索引器？

在我看来， ICollection<T>可以做IList<T>可以做的事情，只是以一种更冗长且可读性更低的方式。

什么样的场景会更易读/更有效，更符合 SOLID 原则，或者以任何方式使用ICollection<T>而不是IList<T>更好？

编辑：

重复问题的答案没有回答我的问题，因为他们避免谈论ICollection<T>可以做IList<T>所做的事情，但方式更丑陋。

如果他们都做同样的事情，为什么不使用更清洁的IList<T>呢？

我在这里收到了更好的答案： https://www.reddit.com/r/csharp/comments/dl9xao/why_use_icollectiont_over_ilistt/

Answer 1

答案是非常主观的。 更多的是关于你需要多少。

• 如果您只需要遍历所有项目，则更喜欢IEnumerable<T>
• 如果您需要操作集合（ Add 、 Remove等），应该使用ICollection<T> 。
• 如果您要经常使用 Index，请使用IList<T> 。
• 如果您打算提前进行各种操作 go 并使用List<T> 。

但是在这些情况下，有IReadonlyCollcetion<T>和IReadonlyList<T> ，这使得返回的集合不可变，并且应该再次出现在 IEnumerable 之后，但优先于ICollection<T>和IList<T> 。

最终目标始终是尽可能使用抽象类型。 这是基于Code for the interfaces not for the implementation 。

编辑：对于这个问题，我会说需要索引是首选一个而不是另一个的主要因素。

Answer 2

如果你从开销的角度来看这个，我认为你最好的选择是两者之间的中介， ISet<T>和它的实现HashSet<T> 。

Set 经常被忽视，但由于不依赖于排序，因此在确定“所有权”和节省空间方面非常有效。

编辑（2020 年 11 月 18 日） -重要的是要注意，在将项目添加到 HashSet 后，将计算它的 HashCode。 这样做的成本可能很高，因此完全抵消了您可能从更快的查找中获得的任何性能优势。

重要的区别在于Add() 、 Remove()和Contains()都变为 o(1) （与IList<T>的典型成本为 o(n) 相比。

如果排序成为问题，还有SortedSet<T> 。

这是一篇很棒的文章，解释了这比我能做的要深入得多。 一个重要的片段：

如果您想要尽可能快的查找但不关心顺序，则HashSet<T>是选择的集合。 相比之下， SortedSet<T>将为您提供排序后的集合，但性能会略有下降。

Answer 3

简短的回答是，您可以将 IList 用于任何元素列表。 实际上，IList 实现了 ICollection，ICollection 实现了 IEnumerable。 您可以根据上下文决定您需要的抽象级别。

有关详细信息，请参阅此链接。