《软件方法（下）》8.2.5.2 属性是否直接描述类（202402更新）（1）

8.2.5.2 属性是否直接描述类

类和属性连在一起说"类的属性"，应该能直接说得通，否则类和属性的搭配是不合适的。这个时候应该找到或建立合适的类，把该属性移进去。

例如图8-57，“人员的组织名称”是“人员的组织的名称”，人员→组织→名称，中间隔了个“组织”，"类的属性"不能直接说得通，需要添加一个“组织”类，把“名称”挪过去。

图8-57 属性要能直接描述类

“属性要直接描述类”这个要求和关系数据库的第三范式“不存在传递的函数依赖”相似。

对于每个属性，我们都这样思考：

“类”能决定“属性”吗？如果能，是怎么决定的？如果不能，还需要什么？

--这个人的姓名叫什么？

--潘加宇

--他为什么叫“潘加宇”？

--没啥理由，他就叫这个。

“姓名”作为“人员”的属性是合适的。

★如果进一步探究，这个人为什么叫“潘加宇”也是有理由的。

理由之一可能是：“潘”是家族的姓，“加”是字辈，这由家族的规则决定。“宇”则来自鲁迅的《无题》：心事浩茫连广宇，于无声处听惊雷。了解了这个规律，还可以进一步推导，“潘加宇”如果有个弟弟，那有可能叫“潘加雷”——但这些知识，不属于系统关注的范围，所以探究到此处就可以——“没啥理由”。

--如果知道专家是潘加宇，小时课酬能定吗？

--能，是1500元/小时。

--是怎么决定的？

--因为潘加宇的级别是“金牌专家”，公司规定“金牌专家”的课酬是1500元/小时。

决定的方式是：专家→专家级别→小时课酬。需要添加一个“专家级别”类，“小时课酬”作为它的属性。

图8-58 “类的属性”的调整

如图8-59左侧，我们可以问：

--如果知道商品是“百事可乐罐装330ml”，数量能定吗？

--不能。

--还需要什么？

--还需要知道是哪张订单。

因此需要一个类，既知道订单，又知道商品。添加“订单项”类，“数量”作为“订单项”的属性。

图8-59 “类的属性”的调整

属性如果放在了错误的类，极有可能会导致大量不同对象的某些属性值相同，而这反过来也可以作为线索：当发现大量不同对象有相同属性值时，可以检查一下，是否有属性放在了错误的类。

就以图8-57为例，如果按照左侧，可能会有如图8-60的一些对象，发现其中“人员”对象345677和345679的“组织名称”属性值相同，都是“腾讯科技（深圳）有限公司”。这时，可以检查一下，是否可能漏了一个“组织”类。

图8-60 一些人员对象

注意，以上是说“可以检查一下”，不一定就需要调整。多个对象的部分属性值相同的情况很常见，好多人姓名叫“张伟”，好多人年龄是18岁，并不一定要分出来另一个类。

可以合并的情况

如果A和B两个类存在1对1的关联，而且B只有一个属性，那么，可以把B合并进A，如图8-61。

图8-61 特定条件下合并类

图8-57提到的“人员”和“组织”并不符合合并的条件。即使“组织”只关注一个属性“名称”，也会出现图8-60的情况，因为可以有很多人员关联到一个组织。

符合合并条件的例子如图8-62的“人”和“出生”。一次“出生”事件只针对一个人，一个人只会出生一次，而且出生只关注一个属性：日期，那就可以把“出生”删掉，在“人”中放置“生日”属性。

图8-62 特定条件下合并类示例

如果一个人可以出生多次（带着前世记忆轮回，可能性趋近于0），或者出生除了时间之外，还要关注出生医院等其他属性（可能性较大），那就不宜合并了。

还可以看出，时间类型的属性实际上是某种事件发生的属性，只不过有的时候被合并到其他类中，看起来成为了该类的属性。如图8-62中，“生日”成为了“人”的属性，类似的还有：“下单时间”成为“订单”的属性等。

导致出现违反本要点的错误的原因有：