前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >[答疑]是否优先用泛化,而不是关联? 课上是说优先用关联

[答疑]是否优先用泛化,而不是关联? 课上是说优先用关联

作者头像
用户6288414
发布2021-11-10 15:06:12
1730
发布2021-11-10 15:06:12
举报
文章被收录于专栏:软件方法

Alan 2021-10-26 10:12

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

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

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

杨雪鸿

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

Alan

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

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

杨雪鸿

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

UMLChina潘加宇

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

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

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

Alan

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

UMLChina潘加宇

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

本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。
原始发表:2021-11-02,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 UMLChina 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档