哇，你的帖子有很多问题和观点。你从微软那里得到的大部分理由都是正确的。让我们从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.
}

这取决于上下文

当你把你的球队作为一个球员列表时，你把足球队的“想法”归结为一个方面：你把“球队”缩小到你在球场上看到的人。这一预测仅在特定情况下是正确的。在不同的背景下，这可能是完全错误的。想象一下你想成为球队的赞助商。所以你必须和团队的经理谈谈。在这种情况下，团队将被列入其经理名单。这两个列表通常不会重叠太多。其他情况包括当前玩家与前玩家等。

语义不清晰

因此，将一个团队视为其球员列表的问题在于，它的语义取决于上下文，并且当上下文发生变化时无法扩展。此外，很难表达您所使用的上下文。

类是可扩展的

当您使用只有一个成员的类（例如IListactivePlayers）时，您可以使用成员的名称（以及其注释）来明确上下文。当有其他上下文时，只需添加一个额外的成员。

类更复杂

在某些情况下，创建一个额外的类可能是过度的。每个类定义都必须通过类加载器加载，并由虚拟机缓存。这会消耗运行时性能和内存。当你有一个非常具体的背景时，可以将足球队作为球员列表。但在这种情况下，您应该只使用IList，而不是从它派生的类。

结论/注意事项

当你有一个非常具体的背景时，可以将一个团队作为一个球员列表。例如，在方法内部，完全可以写：

IList<Player> footballTeam = ...

使用F#时，甚至可以创建类型缩写：

type FootballTeam = IList<Player>

但当背景更广泛甚至不清楚时，你不应该这样做。当您创建一个新的类，而该类将来可能使用的上下文不清楚时，情况尤其如此。警告标志是当你开始向你的班级添加额外的属性（球队名称、教练等）时。这是一个明确的标志，表明班级的使用环境不是固定的，将来会改变。在这种情况下，您不能将球队视为球员列表，但您应该将球员列表（当前活跃、未受伤等）建模为球队的属性。

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

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

虽然我没有像大多数答案那样进行复杂的比较，但我想分享一下处理这种情况的方法。通过扩展IEnumerable<T>，您可以允许Team类支持Linq查询扩展，而无需公开List<T>的所有方法和财产。

class Team : IEnumerable<Player>
{
    private readonly List<Player> playerList;

    public Team()
    {
        playerList = new List<Player>();
    }

    public Enumerator GetEnumerator()
    {
        return playerList.GetEnumerator();
    }

    ...
}

class Player
{
    ...
}

这取决于“团队”对象的行为。如果它的行为就像一个集合，那么可以先用一个普通的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（…）。

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