在计划我的计划时,我通常会从这样的一系列想法开始:

足球队只是足球运动员的名单。因此,我应以以下方式表示: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>继承时,必须考虑什么?


当前回答

指南所说的是,公共API不应透露您是否使用列表、集合、字典、树或其他任何东西的内部设计决策。“团队”不一定是列表。您可以将其实现为列表,但公共API的用户应该在需要知道的基础上使用您的类。这允许您在不影响公共接口的情况下更改决策并使用不同的数据结构。

其他回答

这是一个组合与继承的经典例子。

在这种特定情况下:

球队是一个有附加行为的球员列表吗

or

球队是否是自己的一个对象,恰好包含一个球员列表。

通过扩展列表,您可以通过多种方式限制自己:

您不能限制访问(例如,阻止人员更改名册)。您可以获得所有List方法,无论您是否需要它们。如果你还想列出其他事情,会发生什么。例如,球队有教练、经理、球迷、设备等。其中一些可能是他们自己的名单。你限制了继承的选择。例如,您可能希望创建一个通用的Team对象,然后让BaseballTeam、FootballTeam等继承该对象。要从列表继承,您需要从团队继承,但这意味着所有不同类型的团队都必须对该名册进行相同的实现。

合成-包括一个对象,它给出了你想要的对象内部的行为。

继承-对象成为具有所需行为的对象的实例。

两者都有各自的用途,但这是一个明显的情况,即合成更可取。

当他们说List<T>是“优化的”时,我想他们想说的是,它没有像虚拟方法那样昂贵的功能。所以问题是,一旦在公共API中公开List<T>,就失去了执行业务规则或稍后自定义其功能的能力。但是,如果您在项目内部使用这个继承的类(而不是作为API潜在地暴露给成千上万的客户/合作伙伴/其他团队),那么如果它节省了您的时间,并且它是您想要复制的功能,那就没问题了。从List<T>继承的优点是,您消除了许多在可预见的将来永远无法定制的哑包装器代码。此外,如果您希望您的类在API的生命周期内显式地具有与List<T>完全相同的语义,那么它也可以。

我经常看到很多人做大量的额外工作,只是因为FxCop规则这么说,或者有人的博客说这是一种“糟糕”的做法。很多时候,这将代码转化为设计模式palooza的怪异。与许多准则一样,将其视为可能存在例外的准则。

我只是想补充一点,艾菲尔铁塔和合同设计的发明者伯特兰·梅耶(Bertrand Meyer)会让团队继承List<Player>,而不必太费唇舌。

在他的书《面向对象的软件构造》中,他讨论了GUI系统的实现,其中矩形窗口可以有子窗口。他只是让Window继承自Rectangle和Tree<Window>,以重用实现。

然而,C#不是埃菲尔铁塔。后者支持功能的多重继承和重命名。在C#中,当您子类化时,您继承了接口和实现。您可以重写实现,但调用约定直接从超类复制。然而,在Eiffel中,您可以修改公共方法的名称,因此您可以在团队中将Add和Remove重命名为Hire和Fire。如果Team的一个实例被上传回List<Player>,调用方将使用AddandRemove来修改它,但将调用Hire和Fire虚拟方法。

指南所说的是,公共API不应透露您是否使用列表、集合、字典、树或其他任何东西的内部设计决策。“团队”不一定是列表。您可以将其实现为列表,但公共API的用户应该在需要知道的基础上使用您的类。这允许您在不影响公共接口的情况下更改决策并使用不同的数据结构。

序列化问题

One aspect is missing. Classes that inherit from List can't be serialized correctly using XmlSerializer. In that case DataContractSerializer must be used instead, or an own serializing implementation is needed.
public class DemoList : List<Demo>
{
    // using XmlSerializer this properties won't be seralized
    // There is no error, the data is simply not there.
    string AnyPropertyInDerivedFromList { get; set; }     
}

public class Demo
{
    // this properties will be seralized
    string AnyPropetyInDemo { get; set; }  
}

进一步阅读:当类从List继承时,XmlSerializer不会序列化其他属性

改用IList

我个人不会继承List,而是实现IList。Visual Studio将为您完成这项工作,并创建一个完整的工作流程。看这里:如何获得IList的完整工作实现