我有一个业务对象集合（表示来自数据库的数据），它继承自Collection，并且有一个静态方法，用于调用存储过程，然后使用返回的数据填充其属性。
我的问题是;继承Collection是不对的，因为它没有真正扩展类？或者更好的做法是不继承任何东西，而是维护一个类型为Collection的私有变量？
答案 0 :(得分：2)
如果您的业务对象可以向世界提供通常的收集方法，那么继承Collection<T>就可以了。而且我猜，实际上你添加了一些东西 - 你指定T。
<强> UDATE：
根据作者的评论，发布所有收集方法会使对象可编辑，这是不可接受的。因此，不是继承，而是创建私有字段并使类可枚举。
答案 1 :(得分：2)
如果没有详细了解您正在尝试做什么，很难给出答案。但是，我通常不会继承Collection，因为它没有真正提供足够的虚拟方法来覆盖。这可能会改变你班级的行为，将来有点棘手。
继承的问题在于，如果你使用它，你将永远陷入Collection基类的行为，或者面临复杂的重构。例如，您可能希望添加过滤，搜索和排序操作，此时您需要切换到Collection from Collection。您甚至可能希望在需要BindingList而不是Collection的情况下进行数据绑定。
另一个计划是从ICollection继承或更好地继承IList＆lt; T＆gt;。然后委托给私人收藏会员。这为您提供了最大程度的控制，允许您在不影响公共界面的情况下更改类的内部表示。这样做的问题在于开发类需要更长的时间。
因此，您所面临的是在更快的开发和未来的灵活性之间进行权衡，正如我在开始时所说，从原始帖子中给出的信息判断哪条路可能有点困难。
PS：制作IList＆lt; T＆gt;实现只读，只需从IsReadOnly返回true，然后从改变列表的所有方法中抛出NotSupportedException。
答案 2 :(得分：0)
实际上，最“纯粹”的方法是不在继承对象时添加任何内容。几乎没有人试图做到那么纯粹，但这被认为更纯粹。我们的想法是，您可以覆盖某些方法来“填补空白”，了解您的对象的行为方式，但是您不会添加任何非私有成员。
我不主张尝试那么纯洁。关键是，你所做的不是以任何方式“不纯洁”。 （注意：在使用函数式语言的意义上，我根本不使用“纯粹”和“不纯”。简单来说就是字词定义的一般意义）。
答案 3 :(得分：0)
是的，这是错的。你应该只有一个对象来回收集合。此外，除非有迫切的需要，否则不要将方法设置为静态。新的Blah（）。foo（）没有错。任何体面的JIT都会内联对象创建。
此外，我认为在99％的情况下扩展Collection是错误的:)通常，当人们扩展Collection时，他们真正应该做的只是编写一个List并仅暴露客户真正需要的东西或只使用普通List。 / p>