在阅读this问题的答案后，我想到了这个问题;这基本上表明List<T>没有虚拟方法，因为它被设计为“快速，不可扩展”。
如果这是设计目标，为什么原始设计不包括密封课程？ （我知道现在不可能，看看这会如何破坏客户端代码中的很多子类）
答案 0 :(得分：15)
没有令人信服的理由来封存它。从它衍生出来并没有坏处。我曾经是相反的心态 - 只留下你打算让人们从中获取的东西。但事后看来，没有任何意义。 .NET采用的方法是默认情况下方法是非虚拟的，但默认情况下类是未密封的。 List<T>只是遵循同样的做法。
你想要密封一个类的地方是它覆盖虚拟方法，但进一步的子类化并不容易或明显。从诸如Dictionary<TKey,TValue>之类的集合派生以保持已知类型参数并避免在应用程序中使用时输入它们可能会稍微有用。例如，您可能拥有一个派生自Dictionary<String,String>的QueryString类。
由于没有虚拟方法，所以没有什么可以通过密封来保护课程。
答案 1 :(得分：2)
他们决定不让List<T>封存的原因必然有很多，但是，一种可能性是框架设计团队希望与ArrayList（未封存）平等，以便现有的程序和具有基于扩展ArrayList的设计的框架将能够更容易地升级其设计以使用List<T>。密封List<T>对于这些用途来说是一个真正的死胡同，其中一个强有力的指导性设计选择是允许人们轻松地将现有代码库从ArrayList升级到{{1 }}