Why we don’t recommend using List<T> in public APIs

不推荐List<T>做API
原因有如下两点：
1.首先List<T> 设计之初就没有设计成可扩展的，我们不能重新其任何方法。这就意味着，我们操作List<T>的时候却不
能有任何的通知机制，而Collection<T>却提供了SetItem虚方法以供重写，以便于我们在修改成员信息或者添加成员的
时候可以自定义实现通知机制。
2.其次List<T>有许多的成员在很多的使用场景下是相关联的，这就是我们所说的List<T>对外公开了过多的成员方法，
想象下，ListView中的Items属性返回（包含了众多属性的）List<T>。来看看实际上ListView.Items的返回类型;它的方
式更简单，类似于Collection<T>或ReadOnlyCollection<T>。

由于List<T>与Collection<T>的内容比较多，大家感兴趣可以自己查看下，这里只把Collection<T>的部分片段
列出来了。

public class Collection<T> : IList<T>, IList, IReadOnlyList<T>
{
protected virtual void ClearItems()

protected virtual void InsertItem(int index, T item)

protected virtual void RemoveItem(int index)

protected virtual void SetItem(int index, T item)
}
而且其公开方法大概也只有10来个，而List<T>的公开发方法粗略的估计一下至少也得有30个以上。所以明显的可以看出
来，对于系统内部使用为了方便，List<T>提供了更便利的操作，而且在性能上，存储上做了大量的优化。但是如果作为
API显然有些过于庞大和不可控了。

(原文：http://blogs.msdn.com/b/kcwalina/archive/2005/09/26/474010.aspx)

Why we don’t recommend using List<T> in public APIs,布布扣,bubuko.com