我应该实例化一个集合还是从集合继承？

Question

我在创建课程时多次问过自己这个问题，尤其是那些涉及馆藏的课程，但我从来没有想出满意的答案。这是一个OOP设计问题。

例如，在支票簿注册程序中说我有一类BankAccount。 BankAccounts包含的数据涉及账户名称，账户类型（检查，保存，枚举的枚举）以及其他数据，但最重要的是账户中的账户（存款或取款）的集合。

在这里，我有保持调整的集合两种选择：

1. 实例化的集合，并将其作为BankAccount类中的一员。这就像是说“BankAccount 有一系列调整”。
2. 继承集合。这就像是说“BankAccount 是调整集合。”

我认为这两种解决方案都很直观，当然，两者都有一些优点和缺点。例如，实例化允许类（仅允许单个基类的语言）从另一个类继承，而从继承继承的类可以很容易地控制Add，Remove和其他方法，而无需编写代理方法来“包装'那些。

那么，在这种情况下，哪种方法更好？

Answer 1

对我来说，一个银行账户有一个调整的集合。银行账户不是调整的集合，因为它“是”远不止于此：它也是“是”的名称和类型等

所以，你的情况（以及类似的情况下），我建议你在你的班级里汇总一个集合。

如有疑问，请避免继承。 :-)

我可以进一步争论。为了正确使用继承，子类必须满足Liskov's substitution principle;这意味着，在您的情况下，BankAccount应该是预计在Collection任何位置的有效类型。我不认为是这种情况，因为Collection可能会暴露诸如Add()和Remove()等方法，而您希望对您的银行帐户中的添加和删除调整施加一些控制，而不是让人们自由添加和删除它们。

Answer 2

个人而言，我会说BankAccount有集合Adjustment。它可能会有其他的财产不完全是关于什么已经存入或提取（客户，银行账户类型等）。

在设计方面，我的BankAccount对象会暴露类型为Adjustments的延迟加载属性。

就代码中的使用而言，我会实例化银行账户，如果我需要知道进出账户的内容，我会使用公开的属性。BankAccount将是主要目标，负责提供仅与实例化帐户相关的调整。

Answer 3

实例化，当然。

我同意其他海报关于银行帐户是“更多”而不仅仅是其他项目的集合。 或者，也许你只是选择了一个真正叫喊“实例化”的例子。

例子：

• 如果您的银行帐户需要完全不同的项目，第二个集合会发生什么？ （例如：收集可以操作的人，如夫妻，例如收集信用卡，PayPal账户或其他任何可以在您的银行账户上“运作”的人）。
• 根据语言的不同，集合会暴露出太多的信息：如果另一个对象需要访问Adjustements ...假设您在网页上显示您的移动历史记录，则会自动将您的“集合”用于注入，删除等操作。

Answer 4

我觉得过度地陷入像“这更多是 - 一个还是一个 - ”有点危险 - 在一天结束时，重要的是您的设计如何解决问题，它是如何可维护的等等。事实上，我个人理解面向对象编程的一个转折点就是放弃了“作为名词的对象”。当你深入研究它时，对象就是一个从函数向上的抽象，没有什么更多或更少。

这是一个很长的路要说“有”。 :-)子类很复杂，使用起来很简单。