Alan 2021-10-26 10:12

潘老师， 在课程里讲到用类和属性做集合运算，实在没办法，再用和行为变化解决，我理解计算公式不同，是否是行为变化 ，如下

不同设备，计算租金可能是 设备的生产日期，设备的生产国有关系，如果写在设备规格里，会有一堆 if（日期&&&设备类型&&生产国家）老师说的逻辑运算是不是这样，虽然是在同一个地方做完全部逻辑，内聚，但是用泛化，每个设备类型是一个子类，则逻辑更清晰。修改时也不容易出错。 我在我的项目例子是下面这个 。把登录的行为分开

一般来说，属性和行为两个方向随着业务的发展，不同的子类会有较大的机会存在变化的可能，如果预见子类的类型不多，是否优先用泛化，而不是关联？ 课上是说优先用关联

杨雪鸿

你说的用关联更合适吧，比如抽象出计算公公式，按策略模式来

Alan

用泛化更合适，每种设备的计算租金方式不同

老师课上说通过集合运算，我理解各种条件组合，把不同类型分开，这样代码比较难维护

杨雪鸿

你都没看懂我说的，你说合适就合适吧

UMLChina潘加宇

就是要把各种规则显式放在属性和关联里，尽量消灭if，例如，租金=价格*生产国.费率 实在太复杂，不好处理的，再通过泛化来消灭

（登录）这个也一样，例如，账户类型里放一个属性：验证的正则表达式，账户.验证（账户类型.正则表达式），这样搞不定的话，再通过泛化解决。

策略模式只是把泛化挪了一个级别，换汤不换药

Alan

账户类型里放一个属性--- 一种类型有密码，一种类型没密码，而且登录的行为差别比较大，一个验证密码，一个是验证公众号的授权码，综合衡量，我用的是泛化比较直观

UMLChina潘加宇

可以。在泛化之前先想一想又没有通过关联显式解决的好方法，没有的话再泛化，把变化写在行为里

---