为什么在IList <T>上使用ICollection <T>？

Question

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

但是，由于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>。
• 如果您要经常使用索引，请使用IList<T>。
• 如果您打算进行各种操作，请继续使用List<T>。

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

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

编辑：对于这个问题，我想说索引的需求是优先选择索引的主要因素。

Answer 2

如果您从开销的角度看待这个问题，我认为最好的选择是ISet<T>和HashSet<T>两者之间的中介。

集合通常被忽略，但是由于不依赖于键，因此它们在确定“所有权”方面非常有效，并且由于不依赖于键，因此节省了空间。

重要的区别是Add()，Remove()和Contains()都变成了o（1）（与IList<T>的典型o（n）成本相比。

如果订购成为问题，也有SortedSet<T>。

很棒的article解释说，这比我能做的要好得多。重要片段：

  

HashSet<T>是您的最佳选择，如果您想要最快的查找而又不关心顺序。相反，SortedSet<T>将为您提供排序的集合，但性能会略有下降。

Answer 3

简短的响应是您可以将IList用作任何元素列表。实际上，IList实现ICollection，而ICollection实现IEnumerable。您可以根据上下文决定所需的抽象级别。

有关详细信息，请参见this link。

干杯