当我们分析清楚客户需求设计出用例模型以后,当我们分析清楚客户的业务环境制作出领域模型以后,当我们综合用例模型、领域模型和我们的聪明才智设计出一个又一个的类和它们各自的方法以后,当就在一切都准备就绪只欠东风的关键时刻,一个对象发出了撕心裂肺的怒吼——谁来创建我?!!!一个对象,不管拥有多么强大的功能,不管进行了多么精巧的设计,如果不能被创建,就如同韩信不能做将军,孙膑不能当军师,勾践不能回越国,刘备不能得荆州,一切一切的雄才武略都如废纸一张。既然“创建”对于对象如此重要,我们就来好好探讨一下GRASP中关于对象创建的问题。
3.创建者(Creator)
当我们完成了用例模型、领域模型、对象分析的设计,初步完成了对象设计和职责分配的工作,开始进一步细化的时候,一个我们不得不考虑的问题就摆在我们的面前——谁来创建这些对象?也许现在的你会觉得好笑,这也是问题吗?在软件实际开发过程中,谁需要使用某个对象,就去创建它就行了,有什么好讨论的。但是,我不得不说的是,如果你只是漫不经心地想要随意开发一套软件系统,仅仅是完成自己工作而已,你完全不用考虑创建对象的问题。然而如果你希望开发一套高质量的、低耦合的、封装性和复用性高的软件系统,你必须得认真考虑这个问题。为什么呢?因为系统中如果一个对象A创建另一个对象B,那么对象A就必将与对象B耦合,这个我已经在前面《(原创)一个优秀的软件开发人员的必修课:GRASP(2)低耦合》中提到。我们可以想像,如果在你的系统中,对于对象B,你也去创建,我也去创建,大家都去创建,对象B势必与许多对象发生耦合,耦合度将大大提高;但如果对象B可以都由对象A来创建,然后由对象A向其它需要对象B的对象提供对象B,即其它对象需要使用对象B的时候都向对象A索要,那么整个系统对对象B的耦合将会大大降低,同时对象A和B也可以形成一个封装的、可复用的独立系统,则这个软件系统的设计质量势必提高。所以,对象创建的问题不可不察。
那么为了降低系统耦合,提高系统的清晰度、封装性和可复用性,应该有一些通用的原则,以用于对象职责分配中,关于“创建对象”这类职责的分配。这些原则的描述就在GRASP的“创建者”模式中。
1)创建者模式的描述
如果以下条件之一为真(越多越好),则将创建类A的实例的职责分配给类B(B是对象A的创建者):
1.B包含或组成聚集A。
2.B记录A。
3.B直接使用A。
4.B具有A的初始化数据,并且在创建A时会将这些数据传递给A。因此对于A的创建而言,B是信息专家(关于“信息专家”模式我会在后面描述)。
如果有以上多个选项适用,通常首先条件1(B包含或组成聚集A)。
2)何时使用
在理解创建者模式的时候,我认为一个首先必须理解的问题是,在软件项目的整个过程中,它应该是在什么阶段使用。一个网友曾经发帖问我,他不清楚GRASP一般适应于软件开发的什么阶段。我认为,GRASP作为职责驱动的基本原则,一般适用于对象分析和设计的中前期。在软件项目的前期,也就是需求分析阶段,我们通常是制作用例模型和领域模型。用例模型往往描述的是用户对整个项目提出的所有功能的集合。对于每个功能,我们通常使用用例,并在用例描述中描述该用例的主要流程。因此用例模型描述的通常是需求分析中动态的部分。领域模型往往描述的是用户提出的整个问题空间中的各种事物及它们的相互关系,因此领域模型描述的是需求分析中静态部分。领域模型虽然不是完全,但却是以此为基础,形成软件系统中的软件类。为什么不是“完全”呢?因为软件系统中需要什么类,是软件系统功能的要求。假如在领域模型中的某个对象,它的确是用户问题空间中的事物,但是它在软件系统功能的要求中使用不到它,那么在软件系统中它同样不能成为一个软件类。当我们设计好了软件类以后,我们就将根据用例模型,为所有的软件类分配职责,确定它们各自应具有的行为及相互的协作。每个软件类应当如何分配它们的职责,也就是说用例模型中描述的各个功能应当交给哪个或哪些软件类去实现,这个工作就是对软件类的职责分配。完成这个工作的阶段主要在对象分析的中前期,也正是我们大量运用GRASP的时期。职责分配需要一定的原则,这个原则将是GRASP“信息专家”模式将要讨论的内容。当我们将一个一个的软件类的职责分配好了,其各自的行为和属性也确定下来了,下一步需要考虑的问题就是它们应当在何时,由谁来创建。解决对象创建问题当然应当交给创建者模式来完成。因此不难理解,创建者模式应当运用在对象分析中前期稍靠后一点儿的阶段,即软件类的主要职责及其行为都设计好了,讨论该何时,由谁来创建它的时候。
3)为什么
我们做事往往有个习惯,凡事问个为什么。前面我提到,使用创建者模式的主要目的是可以降低系统的耦合。那么,我们在使用创建者模式的这几个建议的时候是如何降低耦合的呢?这一直是困扰了我很久的一个疑问,Craig Larman对于这一点没有清楚地描述。但是,我们接受一个新事物,如果都没有弄清楚为什么就盲目接受,这是一种十分不严谨的态度。我现在通过我在项目中的一些实践和自己的一点儿愚悟,谈谈自己的看法。
创建者模式告诉我们,如果系统中存在包含者容纳被包含者,或整体聚集部分,则包含者往往是被包含者的最佳创建者,整体往往是部分的最佳创建者。为什么呢?首先,这样的设计易于理解,可读性强。为什么这么说呢,我们用我们常见的单据与单据明细来说明吧。一张单据有多条单据明细,这些单据明细聚集于单据中,是单据的一个部分。对于某张单据,我们只有去填写这张单据,才会去填写它的明细。同样,我们要查看和修改这张单据的明细,首先肯定是找到这张单据。以上这些是我们在实际生活中大家都认同的管理单据的方式。GRASP所提倡的一个十分重要观念就是低表示差异,也就是说实际生活中是怎样的,我们就怎样设计。用更加专业点儿的术语表述为:软件设计应当与用户的问题空间保持低表示差异。正因为如此,我的软件设计中,一个单据对象存在了,它的单据明细对象才可以存在;要得到一个单据明细对象,应当先找到它所在的单据对象。既然单据对象与单据明细对象是如此的逻辑关系,我们假设单据明细对象不是由单据对象创建,而是另一个对象X,那么对象X即要创建单据对象,又要创建单据明细对象,还要维持单据对象与单据明细对象的聚集关系。这样的设计不难看出,代码实现比较复杂,可读性差。不仅如此,其耦合度也必然增加。对象X与单据对象和单据明细对象都需要耦合,单据对象与单据明细对象之间同样需要耦合。如果修改一下设计,对象X创建单据对象,而单据对象去创建单据明细对象,则对象X只与单据对象耦合,单据对象再与单据明细对象耦合,耦合度就降低了。所以,包含者创建被包含者,整体创建部分可以有效降低耦合。同时,这样的设计,单据明细对象的创建只与单据对象有关,整个系统都由单据对象向其它对象提供单据明细对象,那么单据对象与单据明细对象则可以比较容易地形成一个关于单据的独立系统。这样一个独立系统可以比较便利地应用到其它需要使用单据的地方,其可移植性也就提高了。
尽管包含者往往是被包含者的最佳创建者,整体往往是部分的最佳创建者,但是在一个软件系统中,并不是所有类都有它的包含者或者整体。如果没有,谁应当创建它呢?记录者当然是另一个可以考虑的人选。仓库管理员管理进出库是ERP系统一个非常重要模块。在实际生活中,一批产品存入仓库,仓库管理员当然是需要填写入库单。这个入库单在仓库管理员填写之前,本没有,是仓库管理员填写之后才有,我们是不是可以说仓库管理员创建了一个入库单。既然现实生活中如此,我们在软件设计中是不是也应该由仓库管理员对象负责创建入库单对象,符合低表示差异,不言而喻也符合低耦合。同样,在这个软件系统中仓库管理员填写入库单,在其它的系统中也同样是仓库管理员填写入库单。仓库管理员与入库单这对封装的独立体也同样可以应用到别的系统,可移植性和封装性也得以提高。因此记录者创建记录内容也是我们可以考虑的一个方案。
如果我们正在设计的软件类也没有记录者,这可如何是好?具有创建这个类所需数据的那个类可以考虑,那个类就是信息专家(什么是“信息专家”,我会在以后对信息专家模式的文章中详细描述)。在我们的设计过程中,很多类的创建是需要一些初始化数据的。最典型的就是我们的vo(值对象)。在java程序中,vo往往是用来传输数据的,也就是说创建vo的初始化数据就是这些它需要传递的数据。如果这些数据在某个Action中,创建vo的当然就是这个Action。而如果这个vo的初始化数据来自BUS,则该vo的创建当然应当是这个BUS中。
如果以上方法还不行,那我们就只有找使用者了。寻找使用者是我们创建类最常用的一种方法,但它的缺点也非常明显。正如前面我描述的,我们系统中对某个软件类的使用可能分布到系统的各个角落。当我们因为某个需求需要修改这个类的时候,我们根本不知道谁在使用它。正因为如此,这样的修改变得如梦魇一般,不断地搜索,不断地修改。我们前面说过,合理的软件构造是为了使我们的变更代价最小,而这样的变更将使我们的代价太大了,也许一个不经意的变更错误将造成我们的系统中一个意想不到的地方发生异常。故我们变更后测试的代价也就因此而增大。总之,寻找使用者作为创建者是我们业务分析阶段最后的终极选择。
4)创建者模式是原则,不是准则
“创建者模式是原则,不是准则”难道“原则”和“准则”还有不同吗?当然。创建者模式是原则,所以我们在业务分析阶段应当尽量遵守。但创建者模式不是准则,因为并非我们的所有软件类都必须遵守。为什么这么说呢?随着项目的进行,我们的分析设计就不再停留在业务的分析上,各种具体的框架和技术将不断引进项目中,这时对象的创建就不一定符合创建者模式。比如,为了提高系统的性能和可维护性、更好地处理对象的创建与回收等复杂的问题,我们常常把对象的创建交给工厂,如spring的beanFactory、hibernate的sessionFactory等等。“工厂”不论是“具体工厂”还是“抽象工厂”,都不符合创建者模式中的任何一个条件。为什么呢?因为创建者模式中的各个条件都是来自对领域模型和设计模型的分析,说得更加直白一点儿就是对客户现实世界的分析,与技术无关。在技术领域的对象分析和设计已经超出了创建者模式适用的范围,这更多的是出现在对象分析和设计的中后期。所以,正如我前面所述的,创建者模式适用的时期,是对象分析和设计的中前期,对象的业务分析稍晚一点儿的阶段。
总之,合理地创建对象可以有效的提供可读性、降低耦合度、提高系统的封装性和可移植性,我们应当引起重视。
分享到:
- 2007-01-30 14:58
- 浏览 5563
- 评论(9)
- 论坛回复 / 浏览 (9 / 6189)
- 查看更多
相关推荐
Joseph_Lin 创建的 bizinfo 项目 一、简介 Business Information System is developed for business migrations in Australia. The system graps the business information (e.g., business sale, migration ...
2. **LeetCode**:这是一个流行的在线平台,提供各种算法和数据结构问题供程序员练习。通过解决LeetCode上的问题,你可以提升编程和解决问题的能力。 3. **Trie(字典树)**:Trie是一种字符串搜索的数据结构,可以...
creating graps and charts, integrating external resources (static as well as streaming); visualizing information on maps; working with colors and scales; utilizing the different D3.js APIs; and much ...
JESD79-2F DDR2 JESD79-3F DDR3 JESD79-4D DDR4 JESD79-5C DDR5 JESD209-2F LPDDR2 JESD209-3C LPDDR3 JESD209-4E LPDDR4 JESD209-4-1A LPDDR4X JESD209-5C LPDDR5(X)
COMSOL二维光子晶体角态研究:单胞与超胞能带计算及边界态与角态特性分析,COMSOL二维光子晶体角态研究:单胞与超胞能带计算及边界态与角态特性分析,comsol二维光子晶体角态。 单胞能带,超胞能带,边界态以及角态计算。 ,comsol;二维光子晶体;角态;单胞能带;超胞能带;边界态计算,基于Comsol的二维光子晶体角态及能带边界计算研究
六自由度机械臂抓取动作仿真与代码解析:抓取动画、关节参数变化及轨迹图解详解,六自由度机械臂抓取动作仿真指南:掌握两套代码实现动画与轨迹图模拟学习攻略,六自由度机械臂抓取动作仿真-8 两套关于抓取动作的代码,包括抓取动画、关节角、角速度、角加速度的变化仿真、以及抓取轨迹图 简单易懂好上手~ ,六自由度机械臂;抓取动作仿真;抓取动画;关节角变化;角速度角加速度;抓取轨迹图;两套代码;简单易懂好上手,六自由度机械臂抓取动作仿真演示:代码与轨迹图解
ITC网络广播工具软件
Multisim四位密码锁电路仿真设计:设定、开锁与声光报警功能演示资料包,Multisim四位密码锁电路仿真设计:设定、输入、开锁与报警功能详解,附源文件、原理说明书与演示视频,multisim四位密码锁电路仿真设计 功能: 1.通过拨码开关1进行初始密码设定。 2.通过拨码开关2输入密码,实现开锁判断。 3.如果密码正确,LED绿灯亮,表示开锁。 4.如果密码不正确,LED红灯亮,蜂鸣器鸣叫,声光报警。 资料包含:仿真源文件+原理说明书+演示视频 ,四位密码锁电路、Multisim仿真设计、初始密码设定;拨码开关输入;开锁判断;LED灯显示;声光报警;仿真源文件;原理说明书;演示视频,Multisim四位密码锁电路仿真设计:初始密码设置与智能解锁功能的声光报警展示
俗话说,摸鱼摸的好,上班没烦恼,毕竟谁能拒绝带薪拉屎呢(手动狗头) 这是一个云开发职场打工人专属上班摸鱼划水微信小程序源码,没有后台 直接导入微信开发者工具即可运行,UI简约大气漂亮,只需登录微信公众平台配置完合法域名即可轻松上线。 用户进入摸鱼小程序,可以自由设置薪资,上班时间、下班时间、发薪日、 月工作天数以提醒自己摸鱼,全民打酱油,让自己成为摸鱼冠军,《商鞅摸鱼哲学》 摸鱼不是自我放纵,而是个人实力的积蓄,我们的小目标是晚睡晚起 小程序中的今日待办会提醒用户带薪拉屎和闲逛,下方展示的是距离休息日的天数,距离下一次发工资的天数和节日的天数。
【毕业设计】基于Java的开发的一个集合校园二手交易、拼车、失物招领等功能的app_pgj
个人记录:PICkit3离线烧录流程 使用软件:MPLAB X IDE v5.30 记录时间:20250215
基于Matlab代码的电力系统状态估计与实验仿真研究:扩展卡尔曼滤波和无迹卡尔曼滤波在电力系统动态状态估计中的应用及效果分析,Matlab仿真实验研究:基于扩展卡尔曼滤波器与无迹卡尔曼滤波器对电力系统状态估计的影响及验证,状态估计 电力系统状态估计 Matlab代码 实验仿真研究 电力系统由于测量值和传输误差,还有测量噪声的影响,会对状态估计产生影响。 因此,需要对嘈杂的测量进行滤波,以获得准确的电力系统运行动态。 本文使用扩展卡尔曼滤波器(EKF)和无迹卡尔曼滤波器(UKF)来估计电力系统的动态状态。 扩展卡尔曼滤波EKF、无迹卡尔曼滤波UKF 利用扩展的无迹卡尔曼滤波器估计了动力系统的动态状态。 对WECC 3机9总线系统和新英格兰10机39总线系统进行了案例研究。 结果表明EKF和UKF都能准确地估计电力系统的动态状态。 ,核心关键词:状态估计; 电力系统状态估计; Matlab代码; 实验仿真; 测量值误差; 测量噪声; 扩展卡尔曼滤波器(EKF); 无迹卡尔曼滤波器(UKF); 动力系统; 动态状态估计; WECC 3机9总线系统; 新英格兰10机39总线系统。,Matlab
springboot在线考试--
台达DVP EH3与MS300 PLC&变频器通讯程序的全面解决方案,台达DVP EH3与MS300通讯程序:稳定可靠的频率控制与启停管理系统,台达DVP EH3与台达MS300通讯程序(TDEH-9) 可直接用于实际的程序,程序带注释,并附送触摸屏程序,有接线方式和设置,通讯地址说明等。 程序采用轮询,可靠稳定 器件:台达DVP EH3系列PLC,台达MS300系列变频器,昆仑通态7022Ni 功能:实现频率设定,启停控制,实际频率读取,加减速时间设定。 资料:带注释程序,触摸屏程序,接线和设置说明,后续有技术咨询。 ,核心关键词:台达DVP EH3; 台达MS300; 通讯程序(TDEH-9); 轮询; 稳定; 频率设定; 启停控制; 实际频率读取; 加减速时间设定; 触摸屏程序; 接线方式; 设置说明; 技术咨询。,台达PLC与变频器通讯程序(带注释、触摸屏控制)
项目资源包含:可运行源码+sql文件 适用人群:学习不同技术领域的小白或进阶学习者;可作为毕设项目、课程设计、大作业、工程实训或初期项目立项。项目具有较高的学习借鉴价值,也可拿来修改、二次开发。 个人账户管理:支持用户注册、登录与个人信息编辑;提供密码找回及账号安全保护措施。 声纹采集:利用麦克风设备录制用户的声纹样本;支持多种录音格式和质量调整,确保采集到清晰、准确的声纹数据。 声纹模板库管理:建立和维护一个安全的声纹模板库;支持声纹模板的添加、删除、更新和查询操作。 声纹比对与识别:运用深度学习算法对输入的声纹数据进行特征提取和匹配;实现快速、准确的声纹身份验证。 多场景应用支持:适用于多种场景,如门禁系统、移动支付、远程登录等;可根据实际需求定制开发相应的应用场景。 实时监控与报警:实时监控系统运行状态,包括声纹识别成功率、处理速度等指标;当出现异常情况时,及时发出报警信息。 数据分析与报告生成:收集并分析声纹识别过程中的数据,如识别准确率、处理时间等;根据用户需求输出包含详细图表说明的专业级文档供下载打印保存。 社区互动交流:设立论坛版块鼓励用户分享心得体会讨论热点话题;定期邀请行业专家举办线上讲座传授实用技巧知识。 音乐筛选与推荐:集成音乐平台API,根据用户的浏览习惯和情绪状态推荐背景音乐,增强用户体验。 数据可视化:提供交互式的数据可视化面板,使非技术用户也能轻松理解复杂的数据集,从而做出更明智的决策。
三相与多相开绕组永磁同步电机仿真模型的先进控制策略探讨与实现,三相与多相开绕组永磁同步电机的Simulink仿真模型与先进控制策略研究,开绕组电机,开绕组永磁同步电机仿真模型、simulink仿真 共直流母线、独立直流母线,两相容错,三相容错控制,零序电流抑制,控制策略很多 三相开绕组永磁同步电机,六相开绕组永磁同步电机 五相开绕组永磁同步电机,五相开绕组电机 ,开绕组电机; 永磁同步电机仿真模型; simulink仿真; 共直流母线; 独立直流母线; 两相容错; 三相容错控制; 零序电流抑制; 控制策略; 六相开绕组永磁同步电机; 五相开绕组永磁同步电机,开绕组电机仿真研究:共直流母线与独立直流母线的容错控制策略
【毕业设计】基于Java的开发的网上汽车租赁管理系统_pgj
csv 模块是 Python 的标准库,无需额外安装。 运行结果如下图: ['姓名', '年龄', '城市'] ['张三', '25', '北京'] ['李四', '30', '上海'] ['王五', '22', '广州']
【毕业设计】基于Java+Springboot+Vue的宠物领养系统_pgj
让前端开发者学习“机器学习”!