这里有很多很好的答案，但我想谈谈我没有提到的东西：面向对象的设计是关于增强对象的能力。

您希望将所有规则、附加工作和内部细节封装在适当的对象中。以这种方式，与此交互的其他对象不必担心这一切。事实上，您希望更进一步，积极防止其他对象绕过这些内部。

从列表继承时，所有其他对象都可以将您视为列表。他们可以直接访问添加和删除玩家的方法。你会失去控制；例如：

假设你想通过了解球员是退役、辞职还是被解雇来区分球员何时离开。您可以实现一个RemovePlayer方法，该方法采用适当的输入枚举。然而，通过从List继承，您将无法阻止对Remove、RemoveAll甚至Clear的直接访问。结果，你实际上取消了足球队课程的资格。

关于封装的其他想法。。。您提出了以下问题：

这使我的代码变得不必要地冗长。我现在必须调用my_team.Players.Count而不是my_team.Count。

你是对的，这对于所有使用你团队的客户来说都是不必要的冗长。然而，这个问题与你将名单球员暴露给所有人的事实相比是很小的，这样他们就可以在没有你同意的情况下玩弄你的球队。

你接着说：

这显然没有任何意义。足球队没有球员名单。这是球员名单。你不会说“约翰·麦克足球先生加入了SomeTeam的球员”。你说“John加入了SomeTeam”。

第一点你错了：去掉“列表”这个词，很明显一支球队确实有球员。然而，你用第二个击中了要害。你不希望客户端调用ateam.Players.Add（…）。你确实希望他们调用ateam.AddPlayer（…），而你的实现（可能还有其他事情）会在内部调用Players.Add（…）。

希望您能够看到封装对于增强对象的能力是多么重要。您希望让每个类都能很好地完成其工作，而不必担心其他对象的干扰。

允许人们说

myTeam.subList(3, 5);

有什么意义吗？如果不是，那么它不应该是一个列表。

我只是想补充一点，艾菲尔铁塔和合同设计的发明者伯特兰·梅耶（Bertrand Meyer）会让团队继承List＜Player＞，而不必太费唇舌。

在他的书《面向对象的软件构造》中，他讨论了GUI系统的实现，其中矩形窗口可以有子窗口。他只是让Window继承自Rectangle和Tree<Window>，以重用实现。

然而，C#不是埃菲尔铁塔。后者支持功能的多重继承和重命名。在C#中，当您子类化时，您继承了接口和实现。您可以重写实现，但调用约定直接从超类复制。然而，在Eiffel中，您可以修改公共方法的名称，因此您可以在团队中将Add和Remove重命名为Hire和Fire。如果Team的一个实例被上传回List<Player>，调用方将使用AddandRemove来修改它，但将调用Hire和Fire虚拟方法。

正如所有人都指出的那样，一队球员并不是一个球员名单。世界各地的许多人都犯了这个错误，可能是不同专业水平的人。问题往往很微妙，偶尔也很严重，就像本例中的情况一样。这样的设计是糟糕的，因为它们违反了利斯科夫替代原则。互联网上有许多很好的文章解释这个概念，例如。，http://en.wikipedia.org/wiki/Liskov_substitution_principle

总之，类之间的父/子关系中有两条规则需要保留：

子项不应要求低于完全定义父项的特征。除了完全定义孩子之外，父母不应要求任何特征。

换句话说，父级是子级的必要定义，子级是父级的充分定义。

这里有一种方法来思考解决方案并应用上述原则，这将有助于避免这种错误。我们应该通过验证父类的所有操作在结构和语义上是否对派生类有效来检验假设。

足球队是足球运动员的名单吗？（列表的所有财产是否以相同的含义应用于团队）团队是同质实体的集合吗？是的，球队是球员的集合球员的出场顺序是否描述了球队的状态？球队是否确保除非明确更改，否则顺序将被保留？没有，也没有球员是否会根据他们在球队中的顺序被纳入/淘汰？不

如您所见，只有列表的第一个特征适用于团队。因此，团队不是列表。列表将是您如何管理团队的实现细节，因此它只能用于存储玩家对象，并使用team类的方法进行操作。

在这一点上，我想指出，在我看来，Team类甚至不应该使用List实现；在大多数情况下，它应该使用Set数据结构（例如HashSet）来实现。

哇，你的帖子有很多问题和观点。你从微软那里得到的大部分理由都是正确的。让我们从List＜T＞开始

列表＜T＞高度优化。它的主要用途是用作对象的私有成员。Microsoft没有密封它，因为有时您可能希望创建一个具有更友好名称的类：class MyList＜T，TX＞：List＜CustomObject＜T，Something＜TX＞｛…｝。现在，这就像做var-list=newMyList<int，string>（）；一样简单；。CA1002：不要暴露通用列表：基本上，即使你计划将此应用程序作为唯一的开发人员，也值得用良好的编码实践进行开发，因此它们会逐渐灌输给你和第二天性。如果您需要任何消费者拥有索引列表，您仍然可以将列表公开为IList＜T＞。这允许您稍后在类中更改实现。Microsoft使集合＜T＞非常通用，因为它是一个通用概念。。。名字说明了一切；这只是一个集合。还有更精确的版本，如SortedCollection＜T＞、ObservableCollection＜T’、ReadOnlyCollection＜T〕等，它们都实现了IList＜T＞，但不实现List＜T＞。集合＜T＞允许重写成员（即Add、Remove等），因为它们是虚拟的。列表＜T＞没有。你问题的最后一部分是正确的。足球队不仅仅是一个球员名单，所以它应该是一个包含球员名单的班级。思考组成与继承。足球队有一个球员名单（名册），而不是球员名单。

如果我正在编写这段代码，那么类可能看起来像这样：

public class FootballTeam<T>//generic class
{
    // Football team rosters are generally 53 total players.
    private readonly List<T> _roster = new List<T>(53);

    public IList<T> Roster
    {
        get { return _roster; }
    }

    // Yes. I used LINQ here. This is so I don't have to worry about
    // _roster.Length vs _roster.Count vs anything else.
    public int PlayerCount
    {
        get { return _roster.Count(); }
    }

    // Any additional members you want to expose/wrap.
}

指南所说的是，公共API不应透露您是否使用列表、集合、字典、树或其他任何东西的内部设计决策。“团队”不一定是列表。您可以将其实现为列表，但公共API的用户应该在需要知道的基础上使用您的类。这允许您在不影响公共接口的情况下更改决策并使用不同的数据结构。