关联优先-《软件方法》8.3.2.1

DDD领域驱动设计批评文集

做强化自测题获得“软件方法建模师”称号

《软件方法》各章合集

《软件方法》最近在第8章做了一些调整，把识别关联的内容提到识别泛化之前，并增加了一些内容：

8.3.1.2 推荐的建模顺序

根据上一小节的知识，推荐识别类的关系时，顺序如图8-96。 

图8-96 建模类关系的顺序

★注：

*图中的人脑思考——也就是本章的知识才是最宝贵的，但为了节省空间，就不一一画出了。

*建模类关系之前的“识别类和属性”，图中略去

*动态建模和静态建模一样，也有多个思考和建模周期，图中略去，后文再关注其中细节。

先静态，后动态

建模时，应该先在类图上建模静态关系，即泛化和关联。然后，做动态建模。通过分析序列图，把用例规约上的系统责任分配到类图上的类，并决定类之间的协作（依赖关系在这里体现即可），如有必要，还要建模状态机图。动态建模不但会给类添加行为，可能还会要求重新思考原来的静态关系。

上一段描述可以看作是识别类关系的一个建模周期，这样的建模周期在分析工作流中可能会重复很多次。

先关联，后泛化

而在“建模静态关系”的一个小建模周期中，应该先建模关联关系，再建模泛化关系。同样，这样的小建模周期在“建模静态关系”时也可能会重复多次。

每一个思考周期中的每一个思考步骤，我们都要充分利用已有的信息来思考，不要急于往下走。

8.3.2 识别关联关系

8.3.2.1 关联优先

尽量把核心域知识通过类之间的关联来表达（属性可以看作和基本类型的关联），实在无法做到这一点时，再考虑引入泛化。

如图8-97，可以如上方的模型，人有两个子类：男人、女人；也可以如下方，人和性别关联。

假设男人和女人计税的规则不同，上方把变化放在操作，操作的实现里会有0.1、0.09等数字，而非核心域概念。下方提炼出0.1、0.09背后的概念“税率”，男人和女人的操作实现是一样的。 

图8-97 尽量把核心域知识通过类之间的关联来表达

★如果觉得以上例子比较偏离实际，也可以改成“结婚”操作，男人的操作实现中有“年龄<22”的内容，女人的操作实现中有“年龄<20”的内容，背后的概念是“性别.法定婚龄”。

GoF的《设计模式》中说到：

Favor object composition over class inheritance.

优先使用对象组合而不是类继承。

意思和“关联优先”差不多，但GoF的《设计模式》中所说的仅仅类似于把模板方法转成策略，并没有进一步提炼核心域概念。

现实中，有的人学习了Fowler的《重构》，把条件语句转成泛化结构，就觉得自己“架构师”了，然后又学了“优先使用对象组合而不是类继承”，搞出若干“策略”，更觉得自己是“高级架构师”了，但这还是换汤不换药。

本书所说的“关联优先”，需要更深入的思考。

8.3.2.2 关联的UML知识点

图8-98是根据《软件方法（上）》2018版本的用例规约得出的分析类图的一部分。 

图8-98 根据《软件方法（上）》2018版本的用例规约得出的分析类图（部分）

图8-98上标注的建模元素，可以看作建模关联时所要思考和表达的基本元素。其他相对“高阶”的建模元素，在讲述相应知识点时再介绍。

8.3.2.2.1 关联名和角色名

如果两个类A和B之间的关联，用“A的B”和“B的A”来称呼，就足以表达领域知识，那么可以不加关联名称和角色名称；否则，应该加上关联名称或角色名称。

如图8-99中，“订单的发票”、“发票的订单”可以表达领域知识，那就不用再加其他信息，但“订单的人员”会有歧义，则需要加关联名称或角色名称。如果两个类之间存在多个关联，那么关联名称或角色名称更是必须的了。

图8-99 可以和不可以忽略关联名称或角色名称的情况

我们说的是“角色名称或关联名称”，也就是说，这两个标注一个即可。角色名称相当于一个类在另一个类中的属性名称，是更严谨的表达，有可能的话，应该优先标注角色名称。

★关联名称也是有映射的。在映射关系数据库时，多对多关联的关联名称可以映射为中间表的表名。不过在很多情况下，由于系统要关注关联的细节，多对多关联在分析工作流已经被分解为两个一对多关联。

当然，如果证据暂时不足，我们可以先不标注角色名称，而是标注关联名称。

我们进一步探讨图8-99中“订单”和“人员”的关联。

在“人员”一端标注“下单人”、“审核人”（如图8-100左上），证据其实是不足的。为什么不是在“订单”一端标注“所下订单”、“所审核订单”（如图8-100右上）？如果暂时无法判定方向，为了严谨两边都加上（如图8-100左下），图上就会密密麻麻，这时还不如只写关联名称“下”、“审核”（如图8-100右下），等到有足够证据时，再在合适位置加上角色名称。 

图8-100 角色名称和关联名称的取舍

不管是标注角色名称还是关联名称，都要付出更多的思考。

有的建模人员可能并不愿意。你问他“A和B是什么关联”，他可能回答“是一个1对多的关联”，就已经觉得自己足够精细了。

有的建模人员即使命名，也是没有经过思考的废话，例如关联名称一律为“有”、“属于”，角色名称就是类名前面加一个a或m，如图8-101。如果是这样，还不如留空，等到映射到设计时再按照套路批量映射。 

图8-101 废话的角色名和关联名

8.3.2.2.2 多重性