这取决于上下文

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

语义不清晰

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

类是可扩展的

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

类更复杂

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

结论/注意事项

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

IList<Player> footballTeam = ...

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

type FootballTeam = IList<Player>

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

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

以前的代码意味着：一群来自街头的人踢足球，他们碰巧有一个名字。类似于：

总之，这个代码（来自m-y的答案）

public class FootballTeam
{
    // A team's name
    public string TeamName; 

    // Football team rosters are generally 53 total players.
    private readonly List<T> _roster = new List<T>(53);

    public IList<T> Roster
    {
        get { return _roster; }
    }

    public int PlayerCount
    {
        get { return _roster.Count(); }
    }

    // Any additional members you want to expose/wrap.
}

意思是：这是一支有管理层、球员、管理员等的足球队

这就是你的逻辑在图片中呈现的方式…

序列化问题

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

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

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

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

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

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

--已编辑

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

--第2版

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

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

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

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

在这种特定情况下：

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

or

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

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

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

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

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

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