指南所说的是，公共API不应透露您是否使用列表、集合、字典、树或其他任何东西的内部设计决策。“团队”不一定是列表。您可以将其实现为列表，但公共API的用户应该在需要知道的基础上使用您的类。这允许您在不影响公共接口的情况下更改决策并使用不同的数据结构。

我想我不同意你的概括。一支球队不仅仅是球员的集合。一支球队有很多关于它的信息——名字、队徽、管理/行政人员的集合、教练组的集合，然后是球员的集合。因此，您的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();
}

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.
}

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

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

这取决于上下文

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

语义不清晰

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

类是可扩展的

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

类更复杂

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

结论/注意事项

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

IList<Player> footballTeam = ...

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

type FootballTeam = IList<Player>

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

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

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

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

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

--已编辑

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

--第2版

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

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

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

我肮脏的秘密：我不在乎别人说什么，我也这么做。.NET Framework以“XxxxCollection”（我头上的例子是UIElementCollection）传播。

那么，是什么阻止了我说：

team.Players.ByName("Nicolas")

当我发现它比

team.ByName("Nicolas")

此外，我的PlayerCollection可能会被其他类使用，如“俱乐部”，而不需要任何代码重复。

club.Players.ByName("Nicolas")

昨天的最佳实践可能不是明天的最佳实践。大多数最佳做法背后没有任何原因，大多数只是社区之间的广泛共识。与其问社区，当你这样做时，它是否会责怪你，不如问问自己，什么更容易阅读和维护？

team.Players.ByName("Nicolas") 

or

team.ByName("Nicolas")

真正地你有什么疑问吗？现在，您可能需要处理其他技术限制，这些限制会阻止您在实际用例中使用List<T>。但不要添加不应该存在的约束。如果微软没有记录原因，那么这无疑是一个“最佳实践”。