问题描述

在规划我的项目时，我通常会从以下思路开始:

When planning out my programs, I often start with a chain of thought like so:

足球队只是足球运动员的名单.因此，我应该用:

A football team is just a list of football players. Therefore, I should represent it with:

var football_team = new List<FootballPlayer>();

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

The ordering of this list represent the order in which the players are listed in the roster.

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

But I realize later that teams also have other properties, besides the mere list of players, that must be recorded. For example, the running total of scores this season, the current budget, the uniform colors, a string representing the name of the team, etc..

那么我想:

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

Okay, a football team is just like a list of players, but additionally, it has a name (a string) and a running total of scores (an int). .NET does not provide a class for storing football teams, so I will make my own class. The most similar and relevant existing structure is List<FootballPlayer>, so I will inherit from it:

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

但事实证明，指南说您不应该从 List<T>.我在两个方面对这个指南感到非常困惑.

But it turns out that a guideline says you shouldn't inherit from List<T>. I'm thoroughly confused by this guideline in two respects.

显然 List 以某种方式优化了性能.怎么会这样?如果我扩展 List 会导致什么性能问题?究竟会破坏什么?

Apparently List is somehow optimized for performance. How so? What performance problems will I cause if I extend List? What exactly will break?

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

Another reason I've seen is that List is provided by Microsoft, and I have no control over it, so I cannot change it later, after exposing a "public API". But I struggle to understand this. What is a public API and why should I care? If my current project does not and is not likely to ever have this public API, can I safely ignore this guideline? If I do inherit from List and it turns out I need a public API, what difficulties will I have?

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

Why does it even matter? A list is a list. What could possibly change? What could I possibly want to change?

最后，如果微软不希望我从 List 继承，他们为什么不让类 sealed?

And lastly, if Microsoft did not want me to inherit from List, why didn't they make the class sealed?

显然，对于自定义集合，Microsoft 提供了一个应该扩展的 Collection 类，而不是 List.但是这个类很裸，并没有很多有用的东西，如AddRange，例如.jvitor83's answer 提供了该特定方法的性能原理，但是慢的 AddRange 不是更好比没有AddRange?

Apparently, for custom collections, Microsoft has provided a Collection class which should be extended instead of List. But this class is very bare, and does not have many useful things, such as AddRange, for instance. jvitor83's answer provides a performance rationale for that particular method, but how is a slow AddRange not better than no AddRange?

从 Collection 继承比从 List 继承要多得多，而且我看不出有什么好处.微软肯定不会无缘无故告诉我做额外的工作，所以我不禁觉得我在某种程度上误解了一些东西，继承 Collection 实际上不是解决我的问题的正确方法.

Inheriting from Collection is way more work than inheriting from List, and I see no benefit. Surely Microsoft wouldn't tell me to do extra work for no reason, so I can't help feeling like I am somehow misunderstanding something, and inheriting Collection is actually not the right solution for my problem.

我看到了一些建议，例如实现 IList.就是不行.这是几十行样板代码，对我没有任何好处.

I've seen suggestions such as implementing IList. Just no. This is dozens of lines of boilerplate code which gains me nothing.

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

Lastly, some suggest wrapping the List in something:

class FootballTeam 
{ 
    public List<FootballPlayer> Players; 
}

这样做有两个问题:

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

1. It makes my code needlessly verbose. I must now call my_team.Players.Count instead of just my_team.Count. Thankfully, with C# I can define indexers to make indexing transparent, and forward all the methods of the internal List... But that's a lot of code! What do I get for all that work?

这只是简单的没有任何意义.足球队没有拥有"球员名单.它是玩家列表.您不会说John McFootballer 已加入 SomeTeam 的球员".您说John 已加入 SomeTeam".您不会将字母添加到字符串的字符"，而是将字母添加到字符串.您不是将一本书添加到图书馆的书籍中，而是将一本书添加到图书馆中.

It just plain doesn't make any sense. A football team doesn't "have" a list of players. It is the list of players. You don't say "John McFootballer has joined SomeTeam's players". You say "John has joined SomeTeam". You don't add a letter to "a string's characters", you add a letter to a string. You don't add a book to a library's books, you add a book to a library.

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

I realize that what happens "under the hood" can be said to be "adding X to Y's internal list", but this seems like a very counter-intuitive way of thinking about the world.

什么是表示数据结构的正确 C# 方式，逻辑上"(也就是说，对人类思维")只是 things<的 list/code> 有一些花里胡哨的东西?