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

Question

在创建课程时，我多次问过自己这个问题，特别是那些涉及收藏的课程，但我从来没有得到满意的答案。这是一个OOP设计问题。

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

在这里，我有两个选项来保存调整的集合：

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

我认为过度依赖语义如“这更多是a还是有a”有点危险 - 最终，重要的是你的设计如何解决问题，如何维护事实上，就个人而言，我理解面向对象编程的方式的转折点就是放弃“作为名词的对象”。当你接下来的时候，对象是一个从函数中提升一级的抽象，或多或少。

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