相关疑难解决方法(0)

为什么不从List <T>继承？

在规划我的程序时,我经常从一连串的想法开始:

足球队只是一个足球运动员名单.因此,我应该代表它:
var football_team = new List<FootballPlayer>();
Run Code Online (Sandbox Code Playgroud)
此列表的顺序表示球员在名单中列出的顺序.

但我后来才意识到,除了仅仅是球员名单之外,球队还有其他属性,必须记录下来.例如,本赛季的总得分,当前预算,统一颜色,string代表球队名称等等.

那么我认为:

好吧,足球队就像一个球员名单,但另外,它有一个名称(a string)和一个总分(a int)..NET不提供用于存储足球队的类,所以我将创建自己的类.最相似和相关的现有结构是List<FootballPlayer>,所以我将继承它:
class FootballTeam : List<FootballPlayer> 
{ 
    public string TeamName; 
    public int RunningTotal 
}
Run Code Online (Sandbox Code Playgroud)

但事实证明,指南说你不应该继承List<T>.我在两个方面完全被这个指南搞糊涂了.

为什么不？

显然List是以某种方式针对性能进行了优化.怎么会这样？如果我延长会给我带来什么性能问题List？究竟会打破什么？

我看到的另一个原因List是微软提供的,我无法控制它,所以我在以后暴露"公共API"后无法改变它.但我很难理解这一点.什么是公共API,我为什么要关心？如果我当前的项目没有并且不太可能拥有此公共API,我可以放心地忽略此指南吗？如果我继承List 并且事实证明我需要一个公共API,那么我将遇到什么困难？

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

最后,如果微软不想让我继承List,他们为什么不上课sealed呢？