这取决于“团队”对象的行为。如果它的行为就像一个集合，那么可以先用一个普通的List来表示它。然后，您可能会注意到，您一直在复制在列表上迭代的代码；此时，您可以选择创建一个FootballTeam对象来包装球员列表。FootballTeam类成为在球员列表上迭代的所有代码的主场。

这使我的代码变得不必要地冗长。我现在必须调用my_team.Players.Count而不是my_team.Count。幸运的是，使用C#，我可以定义索引器以使索引透明，并转发内部List的所有方法。。。但这是很多代码！我做这些工作能得到什么？

封装。你的客户不需要知道足球队内部发生了什么。你的客户都知道，它可以通过在数据库中查找玩家列表来实现。他们不需要知道，这会改进您的设计。

这显然没有任何意义。足球队没有球员名单。这是球员名单。你不会说“约翰·麦克足球先生加入了SomeTeam的球员”。你说“John加入了SomeTeam”。您不向“字符串的字符”添加字母，而是向字符串添加字母。您不向图书馆的图书添加图书，而是向图书馆添加图书。

准确地说：）你会说footballTeam.Add（john），而不是footballTeam.List.Add（john）。内部列表将不可见。

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

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

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

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

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

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

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

你接着说：

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

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

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

首先，它与可用性有关。如果使用继承，Team类将公开纯粹为对象操作而设计的行为（方法）。例如，AsReadOnly（）或CopyTo（obj）方法对团队对象没有意义。与AddRange（items）方法不同，您可能需要一个更具描述性的AddPlayers（players）方法。

如果您想使用LINQ，实现诸如ICollection＜T＞或IEnumerable＜T＞之类的通用接口将更有意义。

如前所述，合成是正确的方法。只需将玩家列表作为一个私有变量来实现。

什么时候可以接受？

引用Eric Lippert的话：

当您构建扩展List<T>机制的机制时。

例如，您厌倦了IList＜T＞中缺少AddRange方法：

public interface IMoreConvenientListInterface<T> : IList<T>
{
    void AddRange(IEnumerable<T> collection);
}

public class MoreConvenientList<T> : List<T>, IMoreConvenientListInterface<T> { }

当他们说List<T>是“优化的”时，我想他们想说的是，它没有像虚拟方法那样昂贵的功能。所以问题是，一旦在公共API中公开List<T>，就失去了执行业务规则或稍后自定义其功能的能力。但是，如果您在项目内部使用这个继承的类（而不是作为API潜在地暴露给成千上万的客户/合作伙伴/其他团队），那么如果它节省了您的时间，并且它是您想要复制的功能，那就没问题了。从List<T>继承的优点是，您消除了许多在可预见的将来永远无法定制的哑包装器代码。此外，如果您希望您的类在API的生命周期内显式地具有与List<T>完全相同的语义，那么它也可以。

我经常看到很多人做大量的额外工作，只是因为FxCop规则这么说，或者有人的博客说这是一种“糟糕”的做法。很多时候，这将代码转化为设计模式palooza的怪异。与许多准则一样，将其视为可能存在例外的准则。

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

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

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

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

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

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

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

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