为什么公开列表<T>不好？
根据FXCop，List不应该暴露在API对象模型中。 为什么这被认为是不好的做法？
我同意这里的“丛林里的人”： List<T>是一个不受约束，臃肿的对象，里面有很多“包袱”。
幸运的是，解决scheme很简单：公开IList<T> 。
它暴露了几乎所有List<T>的方法（除了像AddRange()类的东西AddRange()的准系统接口，它并没有将你约束到特定的List<T>types，这允许你的API消费者使用他们自己的IList<T>的自定义实现者。
为了获得更大的灵活性，考虑将适当的集合暴露给IEnumerable<T> 。
有两个主要原因：
- List <T>是一个相当臃肿的types，许多成员在许多场景中都不相关（对于公共对象模型太“忙”了）。
- 这个类是开封的，但不是专门devise来扩展的（你不能覆盖任何成员）
如果您正在编写将由成千上万或数百万开发人员使用的API，那么这只被认为是不好的做法。
.NET框架devise准则适用于Microsoft的公共API。
如果你有一个没有被很多人使用的API，你应该忽略这个警告。
我想你不想让你的消费者在你的回报中增加新的元素。 一个API应该是清楚和完整的，如果它返回一个数组，它应该返回确切的数据结构。 我不认为这与T有任何关系，而是直接返回List <>而不是数组[]
一个原因是因为List不是你可以模拟的东西。 即使在不太stream行的库中，由于这个build议，我已经看到用于将List对象公开为IList的迭代，并且在后来的版本中决定不将数据存储在列表中（可能在数据库中）。 因为它是一个IList，所以改变客户端下的实现并不是一个突破性的改变，而是让每个人都工作。
其中一个原因是用户将能够更改列表和列表的所有者不知道这一点，而在某些情况下，它必须做一些东西后，添加/删除项目/从列表中。 即使现在不需要，也可以成为未来的要求。 所以最好将addXXX / RemoveXXX方法添加到类的所有者，并暴露列表IEnumerable或（我认为更好）暴露它作为一个IList，并从WindowsBase使用ObservableCollection。
