您将如何建模表示实体生命周期不同阶段的对象？

Question

我认为这种情况在业务工作流中很常见，例如:贷款管理。

这个过程从贷款申请开始，然后是贷款提议，‘活’贷款，也许还会完成贷款。

• 所有这些对象都是相关的，并且共享许多字段。
• 所有这些对象都有许多对每个实体都是唯一的字段。
• 对象的多样性可能很大，两者之间的转换可能不是线性的(例如:单个贷款申请可能以几种不同类型的贷款结束)

你会怎么模拟这个？

一些备选方案：

• 每种类型的实体都包含相关字段(可能将相关字段分组为子实体)--导致数据重复。
• 每个对象的实体，但不是重复的数据，每个对象都有对其前身的引用(贷款不包含贷款程序的详细信息，而是对贷款应用程序的引用)--这会导致对象结构和创建方法之间的耦合。如果我们改变贷款申请，它不应该影响贷款实体的结构。
• 一个大型实体，包含整个生命周期的字段--这可以创建包含多个字段的“巨型对象”。当阶段之间存在一对多或多到多的关系时，它也不能很好地工作。

Answer 1

对我来说，最让人眼花缭乱的事件之一是学习基于颜色的建模。它完全改变了我设计系统的方式。

关键是在面向对象的设计中有四种原型：

1. 时间间隔代表一个事件或一段时间.例如，申请贷款是一个瞬间，从申请到结束贷款的整个过程将是一个间隔。
2. 角色代表在某个时间间隔内的参与者。坚持贷款，申请人将是一个角色，贷款官员将是另一个，承销商将是第三个。
3. 描述符表示对象的标签或“类”。例如，您可能有一个描述家庭贷款与汽车贷款，但贷款本身是基本相同的。描述符还可以充当工厂。我通常在人们通常使用Enum的地方使用描述符。
4. 人/地方/物代表有形的有形物体。迈克尔布朗是一个人，全球公司总部是一个地方，戴尔精密笔记本电脑的序列号是12345是件事。(请注意，我的戴尔精密笔记本电脑可能会在戴尔的电子商务系统中附加一个描述符)。

这是一个of模型的4个基本元素.这就是它与你的问题的关系。

最开始的原型是时间间隔。如果您还记得基本面向对象编程的指导方针之一“对象是名词，方法是动词”，您可能会倾向于将贷款申请表示为申请者对象上的方法"ApplyForLoan“，并将有关应用程序的所有信息存储在单个贷款对象上。然后，您可能会倾向于在贷款上有一个"LoanStatus“枚举，该枚举基本上列出贷款在处理过程中所经历的所有阶段。

更好的方法是拥有一个应用程序矩对象。以及申请者角色对象。角色依附于人/地方/事物，并参与瞬间(在实践中，我通常把创建瞬间对象的责任交给我认为是“演员”的角色。在贷款申请中，申请人是“参与者”。

在这本书中，科德谈到了前辈和后人的概念。也就是说，在执行RiskAssessment之前，必须有一个应用程序。这些时刻形成了与正在创建的系统相关的一系列事件。例如，贷款审批系统不会关心贷款的支付，因此它们不会被映射为系统的一部分。尽管可能会有另一个系统来处理这些细节。

这种方法的优点是系统变得非常灵活和可扩展，因为与其将新的字段和方法添加到臃肿的"LoanCustomer“对象(或者更糟的是从贷款客户派生来表示客户在系统中可能扮演的不同角色)，我们还创建了随着系统需求的增长而产生的新角色。

我强烈建议把这本书捡起来看一遍。这是一种非常强大的技术，尽管UML不再受欢迎，概念是永恒的。

Answer 2

如果我是你，我会保持我的数据不变。这是安全和简单得多的理由；当你管理金钱，这感觉特别重要。

贷款申请过程的每个阶段都将由自己的类表示，以最适当的方式描述该阶段，并链接到前一个阶段。

在它便宜的地方，我会复制上一阶段的数据:例如数字。如果您使用的语言是字符串是不可变的，并且您只需要复制一个引用，那么字符串也很容易“复制”。

如果必须与前一阶段(数据表、文档扫描等)共享大量数据，则这些数据可能形成自己的对象，这些对象来自使用该数据的每个阶段。

当然，我也会把这些对象的每个子对象都保持不变。如果报价列表发生了变化，则它是另一个表示更改的对象，包含新旧列表，都是不可变的。

优点：

• 您的数据映射非常简单，因此与业务人员交谈变得更容易。
• 您可以全面了解您的数据是如何演化的，对于bug搜索或测试、故障排除、报告和审计非常有用。
• 您将永远无法通过数据修改逻辑中的错误丢失数据。(如果您执行多线程，那么整个类的数据竞争和并发修改错误也就会消失。)
• 每个阶段都有最好的、不妥协的表示，也没有额外的“未使用”字段。
• 您的类型系统帮助您始终使用正确的工作流阶段对象，在编译时检测到许多可能的错误。

缺点：

• 你有很多相互依赖的类，有时看起来很相似。
• 更改业务逻辑可能需要对代码进行更多的更改。

这是描述这种方法的文章的关键部分。它使用Scala，但是它用简单的英语解释了基本原理。可以随意查看前面的部分，这些部分显示了可变对象方法的缺点。

Answer 3

在阅读你的问题时，我听说有很多关系。贷款有申请。贷款有0或更多的优惠。等等

我可以想象这样的事情(Java伪代码)：

public class Loan {
    private Application application;
    private List<Offers> offers;
    // etc
}

为了尽量减少重复，我想我应该让每个子元素指向父元素：

public class Application {
    private Loan parent;
    private List<Address> addresses;
    private List<Person> responsibleParties;
    private State currentState;
}

这样，Loan的元素就可以导航到相关的元素来获取数据。

这方面有一些明确的缺点。例如，如果将其存储在数据库中，则可能会被迫加载整个Loan图，而您所需要的只是一点点信息。此外，一些重复是可以的，甚至鼓励。考虑一个人的地址。当前地址可能不是其应用程序中使用的地址。在这种情况下，您可能需要防御性副本。应用程序地址不应更改，但当前地址将更改。记住这其中的一部分是文档，去复制是有问题的，这一点很有用。