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

我有一个关于类的建模和底层数据库设计的问题

简而言之，情况如下：目前我们有头寸和账户对象和表格，它们之间的关系是一个头寸“有一个”账户（一个账户可以有多个头寸）。这是一个简单的聚合，在DB中由保存帐户ID作为外键的位置表处理

我们现在需要通过交易和投资组合来扩展这种“向下”。一项或多项交易构成头寸（但交易本身不是头寸），一项或多项投资组合构成账户（但投资组合本身不是账户）。交易与投资组合相关联，就像头寸与账户（“有a”）相关联一样。请注意，仍然可以有一个没有交易的头寸和一个没有投资组合的账户（即，不强制要求将所有现有对象分解为子组件）

我的第一个想法是简单地实现以下目标（前两个类已经存在）：

我认为（潜在的）问题很明显：从交易开始，你可能会进入不同的账户，这取决于你是采取持仓路线还是投资组合路线。当然，这是不应该发生的，创建和存储对象的代码也不应该产生这样的不一致性。我想知道，理论上可能存在不一致的数据库这一事实是否意味着设计有缺陷

---

期待您的反馈。

设计没有缺陷，只是因为从A类到D类有两种方式，一种是B类，另一种是C类。这种“正方形”经常出现在OOP类模型中，有时并不明显，特别是如果路径中有更多类的话。但正如Dan提到的，业务语义总是决定这样一个正方形是否必须通勤（在数学意义上）

就我个人而言，我在UML图中这样一个正方形内画了一个

=

符号，表示它必须通勤。我还注意到UML注释中的精确公式，在我的示例中是

对于类

a

的每个对象

a

：

a.B.D=a.C.D

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

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

---

我不认为它本身就意味着有缺陷的设计。最后，它归结为您的业务逻辑，以避免采取一致的状态并将其变成不一致的状态。我现在能看到的唯一解决办法是将投资组合和头寸分组，这样你就可以在交易中使用单一参考。谢谢你的反馈，丹。虽然将职位和投资组合分组在理论上是一种解决方案，但在实践中，它并不能很好地满足需求（它们实际上是完全不同的概念，所以它们应该有不同的类）。我想我们可以继续我提出的设计，只是确保业务逻辑避免不一致。你还可以在交易构造中引入测试，确保提供的头寸和投资组合具有相同的母账户，因此确保在产生时至少捕获不一致。当然，每次这些字段中的一个发生变化时，也必须进行测试。如果对象变得一团糟，可能整个设计都有缺陷？我同意Dan的观点，在构建交易时，添加断言/测试代码，并在数据不一致时抛出异常/诸如此类的东西，并公开要使用的适当API。例如，如果交易可以直接公开正确的账户，而不是通过Trade.Position.Account；交易头寸可以通过ITradePosition接口公开，该接口不公开账户等信息——也就是说，在对象中有引用，但要注意公开的内容——只公开需要的内容。

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