上一个上下文
要了解我的质疑，请先查看问题"Why does .Count work without parentheses?"
在讨论该问题时，为什么在实现Count的类中存在Count()（属性）和ICollection<T>（方法）。那个问题是answered satisfactorily。
但是在评论的答案之下，finoutlook提出了另一个问题：
问题
为了向后兼容，属性Count仍然存在（在后来的LINNet技术的.Net版本中）？
答案 0 :(得分：3)
不，它就是这样，集合可以直接返回有多少元素，而不必迭代它。
Enumerable.Count()有一个优化，如果集合实现ICollection<T>，它将使用该属性而不是一次迭代一个元素集合，否则你必须这样做
这对我来说感觉是一个非常有用的属性。即使框架是在今天使用LINQ创建的，我相信仍然会有类似的东西。 （不可否认，我可以想到我希望看到收集界面的各种变化，但这是另一回事。）
答案 1 :(得分：0)
虽然它可以是真理（仍然是为了向后兼容），但在我看来，向后兼容性并不是这个属性仍然存在的原因。
当你有一个在大多数情况下实现ICollection<T>的类时，将是在内部计算元素的简短方法（在类的私有或受保护的范围内）。
而且一个集合必须知道它有多少元素。就我而言，这是该物业的主要目的。