为何将集合转为ICollection<T>调用Add抛异常？OOP原则相关疑问

咱们先把这个问题的核心点拎出来：数组确实实现了ICollection接口，但它的本质还是固定大小的容器，所以对于ICollection里那些修改集合大小的方法，它根本做不到，只能抛出异常。

先搞懂接口和实现的关系 #

在OOP里，接口定义的是一组“契约”——它告诉调用者“我支持这些操作”，但这里有个关键细节：并不是所有实现该接口的类都必须支持契约里的全部方法。.NET的集合框架里就有很多这样的例子，ICollection就是其中之一：它的设计逻辑里明确说明了，Add、Remove、Clear这些方法，实现类可以选择不支持，这时就该抛出NotSupportedException。

数组的特殊情况 #

数组之所以实现ICollection，完全是为了兼容性——这样数组就能被传入那些接受ICollection参数的方法（比如很多LINQ操作、集合工具方法），不用单独写一套数组的处理逻辑。但数组的核心特性是固定大小，从创建那一刻起它的长度就定死了，根本没办法动态添加元素。

所以当你把string[]强转成ICollection<string>后，调用Add方法时，本质上还是在调用数组的Add实现——而这个实现就是直接抛出异常，告诉你“我是固定大小的，加不了新元素”。

怎么解决这个问题？ #

如果需要一个支持Add操作的ICollection，你得把数组转换成真正的可变集合，比如用ToList()方法：

string[] week = new string[] { "Mon", "Tue" };
ICollection<string> col = week.ToList();
col.Add("Wed"); // 这时候就没问题了

最后再提下OOP原则的点 #

你提到的“什么OOP原则阻止了这个操作”，其实不是原则阻止，而是接口契约的灵活性导致的。里氏替换原则（LSP）说子类应该能替换父类，但这里的情况是，数组作为ICollection的实现，它替换了接口，但不支持接口的部分方法——这其实是.NET框架在“兼容性”和“语义正确性”之间做的权衡：为了让数组能被更多代码复用，允许它实现ICollection，但通过抛出异常来明确告知调用者哪些操作它不支持。

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