我想我不同意你的概括。一支球队不仅仅是球员的集合。一支球队有很多关于它的信息——名字、队徽、管理/行政人员的集合、教练组的集合，然后是球员的集合。因此，您的FootballTeam类应该有3个集合，而不是一个集合；如果要正确模拟真实世界。

您可以考虑一个PlayerCollection类，它像SpecializedStringCollection一样提供一些其他功能，例如在将对象添加到内部存储或从内部存储中删除之前进行验证和检查。

也许，PlayerCollection的概念更适合您的首选方法？

public class PlayerCollection : Collection<Player> 
{ 
}

然后足球队可以是这样的：

public class FootballTeam 
{ 
    public string Name { get; set; }
    public string Location { get; set; }

    public ManagementCollection Management { get; protected set; } = new ManagementCollection();

    public CoachingCollection CoachingCrew { get; protected set; } = new CoachingCollection();

    public PlayerCollection Players { get; protected set; } = new PlayerCollection();
}

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

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

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

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

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

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

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

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

你接着说：

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

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

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

这里有一些很好的答案。我想补充以下几点。

正确的C#表示数据结构的方式是什么？数据结构“逻辑上”（也就是说，“对人类的大脑”）只是一个带有一些铃铛和口哨的列表？

请任何十位熟悉足球存在的非计算机程序员填写空白：

足球队是一种特殊的_____

有没有人说“足球运动员名单”，或者他们都说“运动队”、“俱乐部”或“组织”？你认为一支足球队是一个特殊类型的球员名单，这是你的人的想法，也是你个人的想法。

列表＜T＞是一种机制。足球队是一个业务对象——也就是说，一个表示程序业务领域中某个概念的对象。不要把它们混在一起！足球队是一种球队；它有一个名册，名册是一个球员名单。名册不是一种特定的球员名单。名册是球员名单。因此，创建一个名为“花名册”的属性，它是一个列表<Player>。如果你不相信任何一个了解足球队的人都可以从名单中删除球员，那就让它成为ReadOnlyList＜Player＞。

从列表＜T＞继承总是不可接受的吗？

谁不能接受？我不

什么时候可以接受？

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

程序员在决定是否从List<T>继承时，必须考虑什么？

我是在构建机制还是业务对象？

但这是很多代码！我做这些工作能得到什么？

你花了更多的时间来输入你的问题，这可能需要你为List<T>的相关成员写50次转发方法。你显然不害怕冗长，我们这里讨论的是非常少量的代码；这是几分钟的工作。

更新

我想了想，还有一个理由不把足球队列为球员名单。事实上，将一支足球队建模为也有球员名单可能是一个坏主意。一支球队有一个球员名单的问题是，你得到的是球队在某一时刻的快照。我不知道你在这门课上的商业案例是什么，但如果我有一门代表足球队的课，我想问它一些问题，比如“2003年至2013年期间，有多少海鹰队球员因伤缺席比赛？”或“之前为另一支球队效力的丹佛队球员的跑动码数同比增幅最大？”或是“小猪队今年一路走好吗？”

也就是说，在我看来，足球队似乎是一个历史事实的集合，例如球员何时被招募、受伤、退役等。显然，目前的球员名册是一个重要的事实，可能应该是前锋和中锋，但可能还有其他有趣的事情需要更多的历史视角。

如果您的类用户需要List拥有的所有方法和财产，您应该从中派生类。如果他们不需要，请将List括起来，并为类用户实际需要的方法制作包装器。

这是一个严格的规则，如果你编写了一个公共API，或者其他很多人都会使用的代码。如果你有一个很小的应用程序，并且开发者不超过2个，你可以忽略这个规则。这将为您节省一些时间。

对于小型应用程序，您也可以考虑选择另一种不那么严格的语言。Ruby、JavaScript——任何允许您编写更少代码的东西。

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

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