在计划我的程序时，我经常会从这样一个思路开始：

足球队只是足球运动员的名单。因此，我应该用以下方式表示它：

cs var football_team = new List<FootballPlayer>();

此列表的顺序代表球员在名册中列出的顺序。

但我后来意识到，除了球员名单之外，球队还有其他属性必须记录下来。比如本赛季总成绩、当前预算、球衣颜色、string代表球队名称的a等。

那么我想：

好吧，一个足球队就像一个球员名单，但另外，它有一个名字 (a string) 和一个总得分 (an int)。.NET 没有提供用于存储足球队的类，所以我将创建自己的类。最相似和最相关的现有结构是List<FootballPlayer>，所以我将从它继承：

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

但事实证明，一条准则说你不应该继承自List. 我在两个方面完全被这个指导方针弄糊涂了。

为什么不？

显然List以某种方式优化了性能。为何如此？如果我扩展会导致什么性能问题List？究竟会破坏什么？

我看到的另一个原因List是由 Microsoft 提供的，我无法控制它，所以在公开 “public API” 之后我无法更改它。但我很难理解这一点。什么是公共 API，我为什么要关心？如果我当前的项目没有也不太可能有这个公共 API，我可以安全地忽略这个指南吗？如果我确实继承自List 并且事实证明我需要一个公共 API，我会有什么困难？

为什么它甚至重要？一个列表就是一个列表。有什么可能改变？我可能想要改变什么？

最后，如果微软不想让我继承自List，他们为什么不创建这个类sealed？

我还应该使用什么？

显然，对于自定义集合，Microsoft 提供了一个Collection应该扩展的类，而不是List. 但是这个类很简单，没有很多有用的东西，比如AddRange，为该特定方法提供了性能原理，但是慢AddRange不比不好怎么AddRange办？

继承 fromCollection比继承 from 要做更多的工作List，我认为没有任何好处。微软肯定不会无缘无故地告诉我做额外的工作，所以我不禁觉得我在某种程度上误解了一些东西，而继承Collection实际上并不是解决我问题的正确方法。

我已经看到了诸如实施之类的建议IList。就是不行。这是几十行样板代码，对我没有任何好处。

最后，有些人建议将其包装List在一些东西中：

class FootballTeam 
{ 
    public List<FootballPlayer> Players; 
}

这有两个问题：

1. 它使我的代码不必要地冗长。我现在必须打电话my_team.Players.Count而不是仅仅打电话my_team.Count。值得庆幸的是，使用 C# 我可以定义索引器以使索引透明化，并转发内部的所有方法List……但那是很多代码！所有这些工作我能得到什么？
2. 简单明了没有任何意义。足球队没有“拥有”球员名单。这是球员名单。您不会说“John McFootballer 已加入 SomeTeam 的球员”。您说“John 已加入 SomeTeam”。您不会将字母添加到“字符串的字符”，而是将字母添加到字符串。您不会将一本书添加到图书馆的书籍中，而是将一本书添加到图书馆。

我意识到“幕后”发生的事情可以说是“将 X 添加到 Y 的内部列表中”，但这似乎是一种非常违反直觉的思考世界的方式。

我的问题（总结）

什么是表示数据结构的正确 C# 方式，“逻辑上”（也就是说，“对人的思想”）只是花里胡哨的一种list？things

继承自List<T>总是不可接受的吗？什么时候可以接受？为什么/为什么不？程序员在决定是否继承时必须考虑什么List<T>？