我肮脏的秘密：我不在乎别人说什么，我也这么做。.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>。但不要添加不应该存在的约束。如果微软没有记录原因，那么这无疑是一个“最佳实践”。

什么时候可以接受？

引用Eric Lippert的话：

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

例如，您厌倦了IList＜T＞中缺少AddRange方法：

public interface IMoreConvenientListInterface<T> : IList<T>
{
    void AddRange(IEnumerable<T> collection);
}

public class MoreConvenientList<T> : List<T>, IMoreConvenientListInterface<T> { }

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

这在逻辑上是错误的：

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

这是正确的：

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

正如所有人都指出的那样，一队球员并不是一个球员名单。世界各地的许多人都犯了这个错误，可能是不同专业水平的人。问题往往很微妙，偶尔也很严重，就像本例中的情况一样。这样的设计是糟糕的，因为它们违反了利斯科夫替代原则。互联网上有许多很好的文章解释这个概念，例如。，http://en.wikipedia.org/wiki/Liskov_substitution_principle

总之，类之间的父/子关系中有两条规则需要保留：

子项不应要求低于完全定义父项的特征。除了完全定义孩子之外，父母不应要求任何特征。

换句话说，父级是子级的必要定义，子级是父级的充分定义。

这里有一种方法来思考解决方案并应用上述原则，这将有助于避免这种错误。我们应该通过验证父类的所有操作在结构和语义上是否对派生类有效来检验假设。

足球队是足球运动员的名单吗？（列表的所有财产是否以相同的含义应用于团队）团队是同质实体的集合吗？是的，球队是球员的集合球员的出场顺序是否描述了球队的状态？球队是否确保除非明确更改，否则顺序将被保留？没有，也没有球员是否会根据他们在球队中的顺序被纳入/淘汰？不

如您所见，只有列表的第一个特征适用于团队。因此，团队不是列表。列表将是您如何管理团队的实现细节，因此它只能用于存储玩家对象，并使用team类的方法进行操作。

在这一点上，我想指出，在我看来，Team类甚至不应该使用List实现；在大多数情况下，它应该使用Set数据结构（例如HashSet）来实现。

这取决于“团队”对象的行为。如果它的行为就像一个集合，那么可以先用一个普通的List来表示它。然后，您可能会注意到，您一直在复制在列表上迭代的代码；此时，您可以选择创建一个FootballTeam对象来包装球员列表。FootballTeam类成为在球员列表上迭代的所有代码的主场。

这使我的代码变得不必要地冗长。我现在必须调用my_team.Players.Count而不是my_team.Count。幸运的是，使用C#，我可以定义索引器以使索引透明，并转发内部List的所有方法。。。但这是很多代码！我做这些工作能得到什么？

封装。你的客户不需要知道足球队内部发生了什么。你的客户都知道，它可以通过在数据库中查找玩家列表来实现。他们不需要知道，这会改进您的设计。

这显然没有任何意义。足球队没有球员名单。这是球员名单。你不会说“约翰·麦克足球先生加入了SomeTeam的球员”。你说“John加入了SomeTeam”。您不向“字符串的字符”添加字母，而是向字符串添加字母。您不向图书馆的图书添加图书，而是向图书馆添加图书。

准确地说：）你会说footballTeam.Add（john），而不是footballTeam.List.Add（john）。内部列表将不可见。

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

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

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

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

--已编辑

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

--第2版

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

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

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