当业务对象集合不扩展时，它是否应该从 Collection<T> 继承？答案

【问题标题】：Should a business object collection inherit from Collection<T> when it doesn't extend it?当业务对象集合不扩展时，它是否应该从 Collection<T> 继承？
【发布时间】：2009-04-03 08:12:23
【问题描述】：

我有一个业务对象集合（表示来自数据库的数据），它继承自 Collection，并有一个调用存储过程的静态方法，然后用返回的数据填充其属性。

我的问题是；从 Collection 继承是错误的，因为它并没有真正扩展类吗？或者最好不要继承任何东西，而是维护一个 Collection 类型的私有变量？

【问题讨论】：

XOR 的答案让我意识到，通过从 Collection 继承，当我真的希望它只读时，它使对象可编辑，这表明继承是错误的，而不是我应该封装集合并仅使其可枚举。
非常好的推导。人们必须考虑的不是一种方法的抽象正确性，而是这种方法的实际后果。

标签： c# inheritance oop

【解决方案1】：

如果不详细了解您正在尝试做的事情，很难给出答案。但是，我通常不会从 Collection 继承，因为它并没有真正提供足够的虚拟方法来覆盖。这可能会使将来改变班级的行为变得有些棘手。

继承的问题在于，如果您使用它，您将永远受制于 Collection 基类的行为，或者面临复杂的重构。例如，您可能想要添加过滤、搜索和排序操作，此时您需要从 Collection 切换到 List。您甚至可能想要在需要 BindingList 而不是 Collection 的情况下进行数据绑定。

另一种计划是从 ICollection 或更好的 IList 继承，然后委托给私有 Collection 成员。这为您提供了最大的控制权，并允许您在不影响公共接口的情况下更改类的内部表示。这样做的问题是开发类需要更长的时间。

因此，您面临的是更快的开发和未来灵活性之间的权衡，正如我在开始时所说的那样，从原始帖子中提供的信息判断该走哪条路有点困难。

PS：要使 IList 实现只读，只需从 IsReadOnly 返回 true，然后从更改列表的所有方法中抛出 NotSupportedException。

【讨论】：

【解决方案2】：

如果您的业务对象可以向世界提供常用的收集方法，那么从Collection<T> 继承就可以了。正如我猜想的那样，实际上你添加了一些东西——你指定了T。

乌日：
根据作者的 cmets，所有收集方法的发布都会使对象可编辑，这是不可接受的。因此，他不会继承，而是创建私有字段并使类可枚举。

【讨论】：

【解决方案3】：

其实，最“纯粹”的做法是不在继承对象时添加任何东西。几乎没有人试图变得那么纯粹，但这被认为是更纯粹的。这个想法是您可以覆盖某些方法来“填补空白”关于您的对象的行为方式，但您不会添加任何非私有成员。

我不主张尝试变得那么纯洁。关键是，你所做的绝不是“不纯洁的”。（注意：我根本没有使用函数式语言中使用的“纯”和“不纯”。只是在字典中单词定义的一般意义上）。

【讨论】：

【解决方案4】：

是的，这是错误的。您应该只拥有一个可以恢复 Collection 的对象。此外，除非有迫切需要，否则不要将方法设为静态。 new Blah().foo() 没有任何问题。任何体面的 JIT 都会内联对象创建。

另外，我认为在 99% 的情况下扩展 Collection 是错误的 :) 通常，当人们扩展 Collection 时，他们真正应该做的只是编写一个 List 并只公开客户真正需要的内容，或者只是使用一个普通的 List。

【讨论】：