為什么不繼承列表<T>？在規(guī)劃我的程序時，我通常會從這樣的一連串想法開始：足球隊只是一個足球運動員的名單。因此，我應(yīng)該代表它：var football_team = new List<FootballPlayer>();此列表的順序表示球員在名冊中的順序。但后來我意識到，除了球員名單之外，球隊還有其他的屬性，這必須被記錄下來。例如，本季度的總得分、當前預(yù)算、制服顏色、astring代表團隊的名稱等所以我想：好吧，一支足球隊就像一個球員名單，但除此之外，它還有一個名字(astring)和一個連續(xù)的總分(int)。NET不提供用于存儲足球隊的類，因此我將創(chuàng)建自己的類。最相似和最相關(guān)的現(xiàn)有結(jié)構(gòu)是List<FootballPlayer>因此，我將繼承它：class FootballTeam : List<FootballPlayer> {      public string TeamName;      public int RunningTotal }但事實證明一條指南說你不應(yīng)該繼承List<T>..在兩個方面，我對這條準則感到十分困惑。為什么不行？顯然List在某種程度上優(yōu)化了性能..怎么會這樣？如果我擴展List？到底會有什么突破？我看到的另一個原因是List是由微軟提供的，我無法控制它，所以在公開了一個“公共API”之后，我不能稍后更改它。..但我很難理解。什么是公共API，我為什么要關(guān)心？如果我當前的項目沒有并且很可能沒有這個公共API，我能安全地忽略這個指南嗎？如果我真的繼承了List 和原來我需要一個公共API，我會遇到什么困難？那又有什么關(guān)系呢？清單就是清單。有什么可以改變的？我能改變什么？最后，如果微軟不希望我繼承List，他們?yōu)槭裁床蝗ド险nsealed?我還能用什么？顯然，對于自定義集合，Microsoft提供了一個Collection類，它應(yīng)該被擴展，而不是List..但是這門課很空曠，沒有很多有用的東西，比如AddRange例如。Jvitor 83的答復(fù)提供該特定方法的性能基本原理，但慢的是什么？AddRange不比沒有好AddRange?繼承自Collection是比繼承更多的工作List我看不出有什么好處。微軟肯定不會無緣無故地告訴我要做額外的工作，所以我不禁覺得我誤解了一些東西，并且繼承了一些東西。Collection其實不是解決我問題的正確辦法。我看到了一些建議，比如實現(xiàn)IList..只是沒有。這是幾十行樣板代碼，沒有給我?guī)砣魏魏锰?。最后，有人建議將List在某件事上：class FootballTeam {      public List<FootballPlayer> Players; }這方面有兩個問題：它使我的代碼不必要地冗長。我現(xiàn)在必須打電話my_team.Players.Count而不是僅僅my_team.Count..謝天謝地，使用C#，我可以定義索引器，使索引透明，并轉(zhuǎn)發(fā)內(nèi)部所有方法List..但那是很多代碼！我能從這些工作中得到什么？很明顯沒有任何意義。一支足球隊沒有球員名單。它是球員名單。你不會說“約翰·麥克球員已經(jīng)加入了SomeTeam的球員”。你說“約翰加入了SomeTeam”。您不向“字符串的字符”添加字母，而是向字符串中添加一個字母。你不把一本書加到圖書館的書里，而是把一本書加到圖書館里。我意識到“引擎蓋下”發(fā)生的事情可以說是“在Y的內(nèi)部列表中添加X”，但這似乎是一種非常違背直覺的思考世界的方式。我的問題(摘要)什么是正確的C#表示數(shù)據(jù)結(jié)構(gòu)的方式，它“邏輯上”(也就是說，“對人類的思維”)只是一個list的things有幾個鐘聲和口哨？是從List<T>總是不能接受？什么時候可以接受？為什么/為什么不呢？程序員在決定是否從List<T>還是不？