使用面向对象设计的困惑..需要帮助答案

【问题标题】：Confusion using object oriented design .. need help使用面向对象设计的困惑..需要帮助
【发布时间】：2011-06-11 04:49:28
【问题描述】：

假设我们有一个 Order 类和 OrderManagerService 类。

订单类：[一些状态和作用于状态的方法]

OrderManagerService 类：[没有状态。仅遵循静态方法]

问题：假设我们在后面使用关系数据库。我们的目标是更新订单状态。那么，状态需要在数据库中更新。我关心的是把 updateStatus 方法放在哪里。

好吧，第一个选项似乎在封装之后。但是，我个人不喜欢它，因为我们最终可能会从实体对象调用 DAO 层 [也许，这可能没问题]。想知道什么是正确的设计选择，为什么？非常感谢任何帮助。

【问题讨论】：

【解决方案1】：

选项 2 - 创建一个新方法作为 OrderManagerService.updateOrderStatus？

为什么？

您的服务层应该封装工作的逻辑业务单元，在您的情况下，UOW 是

你会用事务划分 updateOrderStatus(...) 。并且服务仍然是无状态的。

【讨论】：

【解决方案2】：

我认为 OrderManagerService 应该有一个 Order 类项的数组。这样您就可以遍历每个项目并更新那里的状态。或者，如果您正在寻找访问单个订单项目，请通过 Order 类直接访问它并在那里更新它。

在您当前的设置中，updateStatus() 应该在 Order 类中。

【讨论】：

【解决方案3】：

observer pattern怎么样？

updateStatus() 将在 Order 类中，由 OrderManagerService 类观察。

每次您更改状态（或任何其他）时，经理都会看到它并在需要时执行一些操作（例如更新数据库中的状态）。

管理器可以在创建实例并在 getOrder() 方法中返回时绑定到 Order。

如果订单的一个实例被销毁，您还可以实现一些方法来解除 Manager 与订单的绑定（仅在非托管语言中关注）。

【讨论】：

【解决方案4】：

由于您的问题的标题包含“使用面向对象的设计”，因此我将状态转换逻辑放在 Order 本身中，因为对象应该封装除了数据之外的行为。

服务中包含的所有行为都可以比作Anemic Domain Model，这是否是坏事由您决定 - 对此有很多争论。

【讨论】：

【解决方案5】：

为什么会有一个单独的 OrderManagerService 类？我会将所有这些方法都放入 Order 中。

（这可能在理论上不正确或不符合 gang-of-four 设计模式，但我不在乎，因为它更有意义。）

【讨论】：

hmm .. Order 类实例代表一个特定的订单。假设我们结合了一切。如果我们想删除一个订单实例，它可能会变得丑陋。因为，它看起来像从另一个实例中删除一个订单实例。嗯..我可能不想走这条路。
怎么样？ orderInstance = 新订单； orderInstance.delete; ?