为何及何时在C#中使用ICollection<T>？附代码示例

先解释你贴的这段代码：

ICollection<ValidationResult> validationResultList = new List<ValidationResult>();

这是面向接口编程的标准写法：用ICollection<T>接口类型声明变量，但实际创建的是它的具体实现类List<T>。核心目的是把「集合的使用方式」和「具体实现逻辑」解耦。

下面具体说什么时候该用ICollection<T>，以及它和List、数组的区别：

1. 用ICollection的核心场景 #

当你的代码只需要基础集合操作时，优先用ICollection<T>：

• 添加/移除元素（Add/Remove）
• 遍历元素
• 获取集合元素数量（Count）
• 判断元素是否存在（Contains）
• 清空集合（Clear）

这些操作足够满足大多数业务场景（比如你示例中的收集验证结果），这时用接口而非具体类有两个关键好处：

• 隐藏冗余功能：List<T>自带很多额外方法（比如Insert、Sort、BinarySearch），如果你的逻辑不需要这些，用ICollection<T>可以避免调用者误用这些方法导致意外（比如随便排序验证结果，打乱原本的错误顺序）。
• 灵活切换实现：如果后续需求变化，比如需要验证结果自动去重，你只需要把new List<ValidationResult>()改成new HashSet<ValidationResult>()，所有调用这个变量的代码完全不用改——因为HashSet<T>也实现了ICollection<T>接口。

2. 和List的区别 #

直接用List<T>声明变量的问题在于耦合度太高：

• 你把变量绑定到了List这个具体实现上，后续如果要换其他集合类型，必须修改所有用到这个变量的地方。
• 如果这个变量是方法的返回值，返回List<T>等于暴露了过多操作权限——调用者可能会随意修改集合的内部结构（比如排序、插入元素），而如果返回ICollection<T>，就相当于明确了「这个集合只支持基础操作」的契约。

当然，如果你的逻辑需要随机访问元素（通过索引取值）、排序、插入指定位置元素这些功能，那必须用List<T>，因为ICollection<T>不提供这些接口。

3. 和数组的区别 #

数组完全不适合你的示例场景，原因很简单：

• 数组的大小是固定的，不能动态添加元素——如果你的验证结果数量不确定，数组根本没法用。
• 数组没有内置的Add/Remove方法，要添加元素只能重新创建新数组，操作非常繁琐。
• 数组只实现了IEnumerable<T>，没有ICollection<T>的便捷操作方法，代码会更啰嗦。

总结 #

一句话判断要不要用ICollection<T>：

当你只需要基础的增删查遍历，且想让代码更灵活、契约更清晰时，用ICollection<T>；
当需要高级功能（索引访问、排序）时，用List<T>；
只有当集合大小固定且不需要修改时，才考虑用数组。

内容的提问来源于stack exchange，提问作者Valmont