Question

我对类的建模和底层数据库设计有疑问。

简单地说，情况如下：目前我们有职位和帐户对象和表格，他们之间的关系是一个职位'有'帐户（帐户可以有多个职位）。这是一个简单的聚合，由位置表在DB中处理，并将帐户ID作为外键。

我们现在需要使用交易和投资组合向下延伸。一个或多个交易构成头寸（但交易本身不是头寸），一个或多个投资组合构成一个账户（但投资组合本身不是账户）。交易与投资组合相关联，就像头寸与账户相关（'有一个'）。请注意，仍然可以使用没有交易的头寸和没有投资组合的账户（即，不必强制将所有现有对象分解为子组件）。

我的第一个想法是简单地进行以下操作（前两个类已经存在）：

class Account;
class Position {
  Account account;
}
class Portfolio {
  Account account;
}
class Trade {
  Position position;
  Portfolio portfolio;
}

我认为（潜在）问题很明显：从交易开始，您可能会在不同的账户中结束，具体取决于您是采用头寸路线还是投资组合路线。当然，这绝不应该发生，创建和存储对象的代码永远不能创建这种不一致。我想知道理论上是否有可能存在不一致的数据库这一事实意味着设计有缺陷？

期待您的反馈。

Answer 1

设计没有缺陷只是因为有两种方法可以从类 A 到类 D ，一种方式超越 B 和一种方式在 C 。这种“正方形”经常出现在OOP类模型中，有时不那么明显，特别是如果路径中有更多的类。但正如丹所提到的，商业语义总是决定这样的广场是否必须通勤（在数学意义上）。

我个人在UML图中的这个方块内绘制一个=符号，表示它必须通勤。另外我注意到UML注释中的精确公式，在我的例子中它将是

对于班级a的每个对象A：a.B.D = a.C.D

如果这样的谓词成立，那么你基本上有两个选择：

相信所有程序员都不要破坏任何代码中的规则，因为它有很好的文档记录
实现一些错误处理（如Dan和algirdas所述），或者，如果您不想在模型中使用此类代码，请创建一个Checker控制器，它检查给定模型实例中的所有条件。

有多个聚合在理论上可以不一致是否可以接受？

1 个答案: