虽然我没有像大多数答案那样进行复杂的比较，但我想分享一下处理这种情况的方法。通过扩展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
{
    ...
}

这取决于上下文

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

语义不清晰

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

类是可扩展的

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

类更复杂

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

结论/注意事项

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

IList<Player> footballTeam = ...

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

type FootballTeam = IList<Player>

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

序列化问题

One aspect is missing. Classes that inherit from List can't be serialized correctly using XmlSerializer. In that case DataContractSerializer must be used instead, or an own serializing implementation is needed.

public class DemoList : List<Demo>
{
    // using XmlSerializer this properties won't be seralized
    // There is no error, the data is simply not there.
    string AnyPropertyInDerivedFromList { get; set; }     
}

public class Demo
{
    // this properties will be seralized
    string AnyPropetyInDemo { get; set; }  
}

进一步阅读：当类从List继承时，XmlSerializer不会序列化其他属性

改用IList

我个人不会继承List，而是实现IList。Visual Studio将为您完成这项工作，并创建一个完整的工作流程。看这里：如何获得IList的完整工作实现

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

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

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

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

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

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

足球队是一种特殊的_____

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

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

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

谁不能接受？我不

什么时候可以接受？

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

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

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

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

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

更新

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

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

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

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

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