为什么认为暴露List是不好的？

在设计一个将被数千或数百万开发人员使用的API时，暴露List被认为是一种不好的做法。.NET框架设计准则是针对微软公共API而制定的。如果你的API没有被很多人使用，那么你应该忽略这个警告。

尽管有些FxCop规则是针对框架设计准则的，可能不适用于某些项目，但即使是为小团队设计的库，遵循这些规则也会有益处。你有没有告诉过5个开发人员，他们需要修改他们的项目，因为你需要对库进行重大更改（比如观察变化）？你的团队中的开发人员是否曾经做出你意想不到的事情，比如修改你打算只读的列表属性的内容？

如果某个准则在你的情况下没有意义，可以在FxCop项目中禁用它，但是请仔细审查准则的原因。

解决方法：根据具体情况禁用不适用的FxCop规则，但要仔细审查准则原因。

为什么将List暴露出去被认为是不好的？

List被认为是不好的原因有两个主要的方面：首先，List是一个相对臃肿的类型，它有很多在许多场景中不相关的成员（对于公共对象模型来说太"繁忙"了）；其次，这个类是一个没有被设计成可以被扩展的非封闭类（你不能覆盖任何成员）。

针对这个问题的解决方法，可以参考Krzysztof Cwalina在这个主题上的观点，具体链接为：blogs.msdn.com/kcwalina/archive/2005/09/26/474010.aspx

在编程中，我们经常会使用List来存储和操作数据。然而，有时候会被认为直接暴露List是不好的。为什么呢？

首先，List是一个庞大的对象，其内部包含了许多额外的信息。这些信息可能对于API的使用者来说并不需要，暴露它们只会增加代码的复杂性和内存的消耗。

其次，List是一个具体的类型，这意味着API的使用者只能使用List，而不能使用其他实现了IList接口的类。这限制了使用者的灵活性，可能会导致在某些情况下无法满足需求。

解决这个问题的方法很简单：使用IList而不是List来暴露集合。IList是一个简化的接口，几乎包含了List的所有方法（除了像AddRange()这样的方法）。使用IList可以避免具体类型的限制，使API的使用者可以使用他们自己实现的IList。

此外，当适用时，还可以考虑将某些集合暴露为IEnumerable，以获得更大的灵活性。

然而，对于Web服务来说，方法无法返回或接受接口类型。这是一个问题，因为SOAP Web服务会将IList转换为T[]数组，而不支持泛型列表类型的序列化。

在使用IList时，不要误以为可以节省内存。虽然使用new List()实例化了IList，但IList变量仍指向内存中的List对象。除此之外，将集合封装起来而不直接暴露给客户端代码通常是有益的。

需要注意的是，使用IList时要小心。Array也实现了IList接口，并且在调用Add和Remove方法时会抛出异常。这可能会令人困惑，因为很多人不会预料到这一点。

为了避免暴露List带来的问题，我们可以使用IList来替代。这样可以减少代码复杂性，提高灵活性，并解决一些特殊情况下的问题。