在计划我的计划时，我通常会从这样的一系列想法开始：
足球队只是足球运动员的名单。因此，我应以以下方式表示：var football_team=新列表<FootballPlayer>（）；此列表的顺序表示球员在名册中的排列顺序。
但我后来意识到，除了球员名单之外，球队还有其他必须记录的财产。例如，本赛季总得分、当前预算、制服颜色、代表球队名称的字符串等。。
所以我想：
好吧，足球队就像一个球员列表，但除此之外，它还有一个名字（一个字符串）和一个连续的总得分（一个整数）。NET没有提供存储足球队的类，所以我将创建自己的类。最相似和最相关的现有结构是List<FootballPlayer>，因此我将从中继承：class FootballTeam：列表＜FootballPlayer＞{ 公共字符串TeamName；公共int RunningTotal}
但事实证明，一条准则说你不应该从List<t>继承。我在两个方面完全被这条准则搞糊涂了。
为什么不呢？
显然，List在某种程度上优化了性能。为什么呢如果我扩展列表，会导致什么性能问题？到底会发生什么？
我看到的另一个原因是List是由Microsoft提供的，我无法控制它，所以在暴露了一个“公共API”之后，我无法稍后更改它。但我很难理解这一点。什么是公共API？我为什么要关心？如果我当前的项目没有也不可能有这个公共API，我可以放心地忽略这个准则吗？如果我确实继承了List，结果发现我需要一个公共API，我会遇到什么困难？
为什么这很重要？列表是一个列表。什么可能会改变？我可能想要改变什么？
最后，如果微软不想让我继承List，他们为什么不把这个类封起来呢？
我还能用什么？
显然，对于自定义集合，Microsoft提供了一个Collection类，该类应该扩展而不是List。但是这个类非常简单，没有很多有用的东西，例如AddRange。jvitor83的答案为该特定方法提供了性能基础，但如何使缓慢的AddRange不比没有AddRange更好？
从收藏中继承比从列表中继承要多得多，我看不出有什么好处。当然，微软不会无缘无故地让我做额外的工作，所以我忍不住觉得我在某种程度上误解了什么，而继承Collection实际上并不是解决我问题的正确方法。
我看到了一些建议，比如实施IList。只是没有。这是几十行样板代码，我什么也没得到。
最后，一些人建议将列表包装为：
class FootballTeam
{
public List<FootballPlayer> Players;
}
这有两个问题：
这使我的代码变得不必要地冗长。我现在必须调用my_team.Players.Count而不是my_team.Count。幸运的是，使用C#，我可以定义索引器以使索引透明，并转发内部List的所有方法。。。但这是很多代码！我做这些工作能得到什么？这显然没有任何意义。足球队没有球员名单。这是球员名单。你不会说“约翰·麦克足球先生加入了SomeTeam的球员”。你说“John加入了SomeTeam”。您不向“字符串的字符”添加字母，而是向字符串添加字母。您不向图书馆的图书添加图书，而是向图书馆添加图书。
我意识到“幕后”发生的事情可以说是“将X添加到Y的内部列表中”，但这似乎是一种非常反直觉的思考世界的方式。
我的问题（总结）
正确的C#表示数据结构的方式是什么？数据结构“逻辑上”（也就是说，“对人类的大脑”）只是一个带有一些铃铛和口哨的列表？
从列表＜T＞继承总是不可接受的吗？什么时候可以接受？为什么？程序员在决定是否从List<T>继承时，必须考虑什么？
首选接口而非类
类应该避免从类派生，而是实现所需的最小接口。
继承中断封装
从类派生会破坏封装：
公开有关如何实现集合的内部详细信息声明可能不合适的接口（公共函数和财产集）
除此之外，这使得重构代码变得更加困难。
类是实现细节
类是一个实现细节，应该对代码的其他部分隐藏。简而言之，System.List是一种抽象数据类型的具体实现，现在和将来可能合适，也可能不合适。
从概念上讲，System.List数据类型被称为“List”这一事实有点转移视线。System.List＜T＞是一个可变的有序集合，它支持用于添加、插入和删除元素的摊余O（1）操作，以及用于检索元素数量或按索引获取和设置元素的O（2）操作。
接口越小，代码越灵活
在设计数据结构时，界面越简单，代码就越灵活。只需看看LINQ有多强大就可以演示这一点。
如何选择接口
当你想“列出”时，你应该先对自己说：“我需要代表一批棒球运动员”。假设你决定用一个类来建模。您首先应该做的是决定这个类需要公开的接口的最小数量。
可以帮助指导此过程的一些问题：
我需要计数吗？如果没有，则考虑实施IEnumerable＜T＞此集合在初始化后是否会更改？如果没有，请考虑IReadonlyList＜T＞。我可以通过索引访问项目是否重要？考虑ICollection＜T＞我向集合中添加项目的顺序是否重要？也许是ISet＜T＞？如果您确实想要这些东西，那么继续执行IList＜T＞。
这样，您就不会将代码的其他部分与棒球运动员集合的实现细节相耦合，只要您尊重接口，您就可以自由更改实现方式。
通过采用这种方法，您将发现代码变得更容易阅读、重构和重用。
避免煮沸板的注意事项
在现代IDE中实现接口应该很容易。右键单击并选择“Implement Interface”。然后，如果需要，将所有实现转发给成员类。
也就是说，如果你发现你正在编写大量的样板，这可能是因为你暴露的函数比你应该暴露的更多。这也是你不应该从类继承的原因。
您还可以设计对您的应用程序有意义的较小接口，也许只需要几个助手扩展函数就可以将这些接口映射到您需要的任何其他接口。这是我在LinqArray库的IArray接口中采用的方法。
如果足球队有一支预备队和主力队呢？
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？我的类名是什么意思？
这里有很多很好的答案，但我想谈谈我没有提到的东西：面向对象的设计是关于增强对象的能力。
您希望将所有规则、附加工作和内部细节封装在适当的对象中。以这种方式，与此交互的其他对象不必担心这一切。事实上，您希望更进一步，积极防止其他对象绕过这些内部。
从列表继承时，所有其他对象都可以将您视为列表。他们可以直接访问添加和删除玩家的方法。你会失去控制；例如：
假设你想通过了解球员是退役、辞职还是被解雇来区分球员何时离开。您可以实现一个RemovePlayer方法，该方法采用适当的输入枚举。然而，通过从List继承，您将无法阻止对Remove、RemoveAll甚至Clear的直接访问。结果，你实际上取消了足球队课程的资格。
关于封装的其他想法。。。您提出了以下问题：
这使我的代码变得不必要地冗长。我现在必须调用my_team.Players.Count而不是my_team.Count。
你是对的，这对于所有使用你团队的客户来说都是不必要的冗长。然而，这个问题与你将名单球员暴露给所有人的事实相比是很小的，这样他们就可以在没有你同意的情况下玩弄你的球队。
你接着说：
这显然没有任何意义。足球队没有球员名单。这是球员名单。你不会说“约翰·麦克足球先生加入了SomeTeam的球员”。你说“John加入了SomeTeam”。
第一点你错了：去掉“列表”这个词，很明显一支球队确实有球员。然而，你用第二个击中了要害。你不希望客户端调用ateam.Players.Add（…）。你确实希望他们调用ateam.AddPlayer（…），而你的实现（可能还有其他事情）会在内部调用Players.Add（…）。
希望您能够看到封装对于增强对象的能力是多么重要。您希望让每个类都能很好地完成其工作，而不必担心其他对象的干扰。
