3

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

简单地说，情况如下：目前我们有Positions和Accounts对象和表格，它们之间的关系是一个 Position '有一个' Account（一个 Account 可以有多个 Positions）。这是一个简单的聚合，由持有账户 ID 作为外键的位置表在数据库中处理。

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

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

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

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

期待您的反馈。

4

1 回答 1

0

该设计没有缺陷，因为从A类到D类有两种方法，一种是B类，另一种是C类。这样的“正方形”会经常出现在 OOP 类模型中，有时并不那么明显，尤其是当路径中有更多类时。但正如丹所提到的，业务语义总是决定这样的广场是否必须通勤（在数学意义上）。

我个人在 UML 图中的这样一个正方形内画了一个=标志，表示它必须通勤。我还注意到 UML 注释中的精确公式，在我的示例中它是

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

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

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