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

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

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

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

--已编辑

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

--第2版

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

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

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

首先，它与可用性有关。如果使用继承，Team类将公开纯粹为对象操作而设计的行为（方法）。例如，AsReadOnly（）或CopyTo（obj）方法对团队对象没有意义。与AddRange（items）方法不同，您可能需要一个更具描述性的AddPlayers（players）方法。

如果您想使用LINQ，实现诸如ICollection＜T＞或IEnumerable＜T＞之类的通用接口将更有意义。

如前所述，合成是正确的方法。只需将玩家列表作为一个私有变量来实现。

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

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？我的类名是什么意思？

设计>实施

您公开的方法和财产是一个设计决策。您从中继承的基类是一个实现细节。我觉得回到从前是值得的。

对象是数据和行为的集合。

因此，您的第一个问题应该是：

这个对象在我创建的模型中包含哪些数据？该对象在该模型中表现出什么行为？这在未来会发生什么变化？

记住，继承意味着“isa”（是a）关系，而组合意味着“hasa”（hasa）关系。在您的视图中选择适合您的情况的应用程序，记住随着应用程序的发展，事情可能会走向何方。

考虑在考虑具体类型之前先考虑界面，因为有些人发现这样更容易将大脑置于“设计模式”。

这并不是每个人在日常编码中都有意识地做到的。但是，如果你在考虑这类话题，你就在踩设计的水。意识到这一点可以让人解放。

考虑设计规范

看看MSDN或Visual Studio上的List<T>和IList<T>。查看它们公开了哪些方法和财产。在你看来，这些方法都像是有人想对足球队做的吗？

足球队逆转（）对你有意义吗？footballTeam.ConvertAll<TOutput>（）看起来像你想要的吗？

这不是一个技巧问题；答案可能真的是“是”。如果您实现/继承List＜Player＞或IList＜Player＞，您将无法摆脱它们；如果这对你的模型很理想，那就去做吧。

如果您决定是，这是有意义的，并且您希望您的对象可以作为玩家的集合/列表（行为）处理，因此您希望实现ICollection＜Player＞或IList＜Player＞

class FootballTeam : ... ICollection<Player>
{
    ...
}

如果您希望您的对象包含玩家（数据）的集合/列表，并且因此希望该集合或列表是属性或成员，那么一定要这样做

class FootballTeam ...
{
    public ICollection<Player> Players { get { ... } }
}

你可能会觉得，你希望人们只能列举一组玩家，而不是数数、添加或删除他们。IEnumerable<Player>是一个非常有效的选择。

您可能会觉得这些接口在您的模型中根本没有用处。这是不太可能的（IEnumerable＜T＞在许多情况下都很有用），但它仍然是可能的。

任何人如果试图告诉你其中一个在任何情况下都是绝对错误的，那就是误入歧途。任何人试图告诉你在任何情况下都是绝对正确的，都是被误导的。

转到实施

一旦您决定了数据和行为，就可以决定实施。这包括通过继承或组合依赖于哪些具体类。

这可能不是一个很大的步骤，人们经常将设计和实现混为一谈，因为很有可能在一两秒钟内在脑海中完成所有这些，然后开始打字。

思想实验

一个人为的例子：正如其他人所提到的，一支球队并不总是“只是”一批球员。你有为球队收集比赛分数吗？在你的模式中，球队是否可以与俱乐部互换？如果是这样的话，如果你的球队是一个球员的集合，也许它也是一个员工的集合和/或分数的集合。然后你会得到：

class FootballTeam : ... ICollection<Player>, 
                         ICollection<StaffMember>,
                         ICollection<Score>
{
    ....
}

尽管是设计，但在C#中，此时无论如何都无法通过从List<t>继承来实现所有这些，因为C#“仅”支持单个继承。（如果你在C++中尝试过这种浮夸，你可能会认为这是一件好事。）通过继承实现一个集合，通过组合实现一个，可能会感觉很脏。而Count等财产会让用户感到困惑，除非显式实现ILIst<Player>.Count和ILIst<StaffMember>.Cunt等，否则它们只会让人感到痛苦，而不会让人感到困惑。你可以看到这是怎么回事；沿着这条路思考时的直觉很可能会告诉你，朝着这个方向前进是错误的（无论对错，如果你这样做，你的同事也可能会这样做！）

简短的回答（太迟了）

关于不从集合类继承的准则不是C#特定的，您可以在许多编程语言中找到它。这是公认的智慧，而不是法律。一个原因是，在实践中，在可理解性、可实现性和可维护性方面，组合通常被认为优于继承。在现实世界/领域对象中，找到有用的、一致的“hasa”关系比找到有用的和一致的“isa”关系更常见，除非你深入抽象，尤其是随着时间的推移和代码中对象的精确数据和行为的改变。这不应该导致您总是排除从集合类继承；但它可能是暗示性的。

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

足球队不是足球运动员的名单。足球队是由足球运动员名单组成的！

这在逻辑上是错误的：

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

这是正确的：

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