这是一个组合与继承的经典例子。

在这种特定情况下：

球队是一个有附加行为的球员列表吗

or

球队是否是自己的一个对象，恰好包含一个球员列表。

通过扩展列表，您可以通过多种方式限制自己：

您不能限制访问（例如，阻止人员更改名册）。您可以获得所有List方法，无论您是否需要它们。如果你还想列出其他事情，会发生什么。例如，球队有教练、经理、球迷、设备等。其中一些可能是他们自己的名单。你限制了继承的选择。例如，您可能希望创建一个通用的Team对象，然后让BaseballTeam、FootballTeam等继承该对象。要从列表继承，您需要从团队继承，但这意味着所有不同类型的团队都必须对该名册进行相同的实现。

合成-包括一个对象，它给出了你想要的对象内部的行为。

继承-对象成为具有所需行为的对象的实例。

两者都有各自的用途，但这是一个明显的情况，即合成更可取。

什么是表示数据结构的正确C#方法。。。

记住，“所有的模型都是错误的，但有些模型是有用的。”

没有“正确的方法”，只有有用的方法。

选择一个对您和/或您的用户有用的。就是这样。经济发展，不要过度设计。编写的代码越少，需要调试的代码就越少。（阅读以下版本）。

--已编辑

我最好的答案是……这取决于情况。从列表继承会将此类的客户端暴露给可能不应公开的方法，这主要是因为FootballTeam看起来像一个业务实体。

--第2版

我真的不记得我所指的“不要过度工程师”的评论。虽然我相信KISS思维是一个很好的指南，但我想强调的是，由于抽象泄漏，从List继承业务类会产生比它解决的问题更多的问题。

另一方面，我认为在少数情况下，仅从List继承是有用的。正如我在前一版中所写的，这取决于情况。每个案例的答案都受到知识、经验和个人偏好的严重影响。

感谢@kai帮助我更准确地思考答案。

如果足球队有一支预备队和主力队呢？

class FootballTeam
{
    List<FootballPlayer> Players { get; set; }
    List<FootballPlayer> ReservePlayers { get; set; }
}

你将如何建模？

class FootballTeam : List<FootballPlayer> 
{ 
    public string TeamName; 
    public int RunningTotal 
}

这种关系显然是有一个，而不是一个。

还是退役球员？

class FootballTeam
{
    List<FootballPlayer> Players { get; set; }
    List<FootballPlayer> ReservePlayers { get; set; }
    List<FootballPlayer> RetiredPlayers { get; set; }
}

根据经验，如果您想从集合继承，请将类命名为SomethingCollection。

你的SomethingCollection在语义上有意义吗？只有当你的类型是Something的集合时才这样做。

就足球队而言，这听起来不太对。团队不仅仅是集合。正如其他答案所指出的，一个团队可以有教练、教练等。

FootballCollection听起来像是足球的集合，也可能是足球用品的集合。TeamCollection，团队的集合。

FootballPlayerCollection听起来像是一个球员集合，如果你真的想这样做的话，它将是继承自List<FootballPlayer>的类的有效名称。

真正的列表＜FootballPlayer＞是一个非常好的类型。如果您从方法返回IList＜FootballPlayer＞，则可能是这样。

总而言之

问问你自己

X是Y吗？或者有X和Y？我的类名是什么意思？

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

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

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

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

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

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

---

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

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

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

你接着说：

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

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

---

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

序列化问题

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的完整工作实现