OO 设计 - 如何根据需求选择业务对象？答案

【问题标题】：OO design - How to pick a business object, given a requirement?OO 设计 - 如何根据需求选择业务对象？
【发布时间】：2018-02-23 21:23:21
【问题描述】：

以下是从use case 中选择的三个业务对象

对于任何给定的用例，我的理解是，如果 actor 属于以下两种情况，则可以将其视为 业务对象：

如果该参与者有自己的本地状态，并且该状态必须不断变化。

或者

如果该参与者可能没有自己的本地状态，但通过关联（组合/聚合）影响另一个参与者的状态。示例：CoinFlipGame 演员影响演员 Player 和 Coin。

为了强调，我想概括一下，任何被视为业务对象的参与者，该参与者都应属于上述两种情况。此外，每个业务对象都是一个 OOP 类（C++/Java/C#）。

您是否同意这种在选择业务对象时派生 OOP 类的方法？
对于给定的用例，如何识别数据库中可以满足需求的业务对象？

【问题讨论】：

每个业务对象都是 OOP 对象，但并非每个 OOP 对象都是业务对象。
@RomainHippeau 查询已编辑，请写下您的评论
你有三个对象。 1) 玩家 2) 硬币 3) 游戏。玩家的选择是一种属性，硬币的面也是如此。 Game 对象是将所有东西连接在一起所需的粘合剂。项目 1 和 2 是您的业务对象。第 3 项只是实现所需的工件。到底什么是业务对象，什么不是真正的学术，取决于你的实现。
@RomainHippeau 我同意this。
FWIW：玩家是演员。不要过度强调业务参与者：-/当然它将表示为业务对象。

标签： java c# c++ database-design

【解决方案1】：

请注意，一般来说，我们必须区分现实世界的对象（或业务对象）和 OOP 对象（例如 JS 对象或 Java 对象）。字符串可能是 OOP 对象（例如，在 Java 中），但它不是业务对象。

在 Java 中，或者更具体地说，在 Java EE 中，实体是一个特殊的 Java 对象，它实例化了一个 Java 实体类 em>，这是一个 JPA 注释为 @Entity 的 Java 类，因此它的所有实例都会自动保存到 Java EE 环境（例如 TomEE）中的持久存储中。

Java 实体旨在表示业务对象。 Java 字符串对象不能是 Java 实体。

任何（业务或 OOP）对象都有自己的（本地）状态，并且还可以通过引用（通过关联）访问它所链接的其他对象的状态。

问题是：领域模型中的哪些业务对象类型（例如玩家、预测、选项、硬币、硬币游戏）必须作为 OOP 类包含在内在 OO 设计模型中？我们也可以说设计模型派生自领域模型，领域模型是从需求中得到的。

领域模型和设计模型都可以以 UML 类模型 的形式制作（可视化为类图），另请参见 SO answer。领域模型描述现实世界的领域，而 OO 设计模型定义要使用特定 OOP 语言（如 Java）实现的 OOP 类。

从领域模型中选择要包含在设计模型中的类取决于您的应用开发项目的信息需求。您必须确定要使用模型（以及生成的 Java 类）捕获的相关信息是什么。

如果您的应用程序的目的是记录和显示有关您的掷硬币游戏的信息，那么我会在设计模型中包含以下类：

玩家（ID、姓名）
游戏（id、日期时间、bettingPlayer、对手、赌注、结果）

这里，bettingPlayer 和 opponent 将是引用属性，它们表示 Game 和 Player 之间的对应关联。

根据领域模型进行这样的设计需要一些识别相关信息项的经验。将业务领域模型转换为平台无关的系统设计模型包括简化和精细化。

领域模型被简化

从对要构建的系统仅具有业务意义但没有信息/计算意义的元素中抽象出来；
压缩模型的某些部分以获得更高效的设计（业务领域模型更关注概念明确性，而系统设计模型更关注效率）

领域模型通过添加对设计至关重要的细节（例如标准标识符、数据类型等）进行详细说明。

这是一个（不是最新的）tutorial，可能会提供一些帮助。

这是一个说明基于模型的开发过程的图表：

【讨论】：

查询已编辑。使用推荐的术语。如果查询仍然不清楚，请告诉我
我还是不明白你的问题：“什么触发业务对象被视为 OOP 对象？”
您是否问过 领域模型 中的哪些业务对象类型（例如玩家、预测、选项、硬币、硬币游戏）必须作为 OOP 类包含在设计模型？顺便说一句，您的用例相当混乱，因为它不代表应用程序设计。
是的，这就是查询
您回答的重点是“经验”。您能否参考任何提供从领域模型中识别 OO 设计模型的案例研究的资源？

【解决方案2】：

一般来说，我会对您的问题说“是”，尽管您可以提供一个更具体或更详细的示例以便不那么笼统地回答。

【讨论】：

【解决方案3】：

我通常不同意，OO 建模与对象的状态有关，尽管这可能是一个有争议的主题，所以你的里程可能会根据你问的对象而有所不同。

您可以从收集您的需求所涉及的“事物”开始，例如 Coin、Player 等。这些是您应用中对象的理想候选对象。

然而，下一步应该不列出这些事物可能具有的变量、它们应该保存的信息或它们之间的关系。这将是数据建模，而不是面向对象的建模。

在面向对象的建模中，下一步是列出职责，并将它们分配给上面的对象“候选人”。在这里使用的一个好工具是CRC Cards。

识别对象需要的“数据”（状态）应该是完全一个实现细节，并且应该最多以非常粗粒度的方式作为建模的一部分，理想情况下根本不应该。 p>

不承担任何责任的对象候选人将不会成为申请的一部分。另请注意，我们不是对现实世界进行建模，因为对象具有与现实世界一样的状态和行为。我们正在对需求进行建模，不多也不少。在现实世界中，骰子并不能真正自己掷骰子，但在软件中却可以。

一句警告：许多现代框架和库不会真正让您以这种方式工作，最值得注意的是，任何需要您创建 Java Bean 的东西都可能对您的 OO 代码不满意。显然，如果您必须使用此类库，您可能不得不妥协您的设计。

【讨论】：

我的理解是，任何成为 OO 设计模型一部分的候选人都应该遵循查询中给出的这两种情况。因为，我为这两种情况中的任何一种创建了一个类实例。否则我不需要创建一个类的实例
OO 建模既是关于状态/信息结构（使用 UML 类图）和行为（使用 UML 状态图和 UML 活动图）。您似乎忽略了这样一个事实，即 OOP 的核心概念是类，它们用类图建模，定义了属性（状态结构）和方法（行为）。 OOP 类/对象与 ORM 技术所示的 SQL 表等数据结构密切相关。
我强烈反对对象与关系数据库、表、ORM 或任何数据结构有任何关系。面向对象设计的核心概念是通过称为对象的主动代理对行为进行建模。 UML 可以对属性进行建模是无关紧要的，事实上，UML 本身是非常无关紧要的，并且对于 OOD 或 OOP 来说无论如何都不需要。
@RobertBräutigam 我的意思是，如果任何 actor 遵循这两种情况（在查询中给出），对于任何给定的域模型，那么对应的 class应该存在于OO设计模型中。为类添加行为是后面的活动，相对容易。
@RobertBräutigam 当然，在 OOP 和 UML 开发的 1990 年代还是婴儿或蹒跚学步的人（由成千上万的智能编程和建模专家开发），可能在他幼稚的胆识中认为“UML 本身无关紧要”。

【解决方案4】：

我认为将业务对象放在一个单独的分类中是非常人为的。对我作为 IT 人员而言，String 和 Person 是相同质量的对象。但与非 IT 人员交谈时，他们会明确地说 String 是人造的，Person 是具体的——因为 Person 是他们日常世界的一个术语。但是Person 就像所有东西一样都是抽象的。我们使用的所有术语都是抽象的。甚至住在我旁边的 John Doe 也是一个抽象概念，因为这个分子聚集体是一个名为 John Doe 的投影。仔细观察，这些分子多年来完全交换，30岁的人和10岁的人没有任何共同之处。

OMG - 越来越哲学了。这也是我投票结束这个问题的原因，主要是基于意见。

【讨论】：

正如我在回答中指出的那样，“String 和 Person 是相同质量的对象”是不正确的。在 Java EE 中，Person 可以成为 Java 实体，而 String 不能。
@GerdWagner 我对 Java 的东西一无所知，并且谈论的是更正式的而不是面向语言的水平。
但在更一般/逻辑/正式的级别上，字符串并不是真正具有对象 ID 和状态的对象。相反，它是一个数据值。它恰好被实现为 OOP 语言中的 String 引用类型的实例。这样的引用类型碰巧被实现为类，就像真正的对象类型一样。
@GerdWagner 现在你正在漂流。状态和 ID 独立于任何对象。顺便说一句：每个对象都有一个隐式 ID，它以编程方式由其地址表示。
@ThomasKilian 我认为我的查询与任何基于 java/C++ 实现的项目的设计阶段有关。为什么这会导致哲学方面的问题？查询已编辑