当我们分析清楚客户需求设计出用例模型以后,当我们分析清楚客户的业务环境制作出领域模型以后,当我们综合用例模型、领域模型和我们的聪明才智设计出一个又一个的类和它们各自的方法以后,当就在一切都准备就绪只欠东风的关键时刻,一个对象发出了撕心裂肺的怒吼——谁来创建我?!!!一个对象,不管拥有多么强大的功能,不管进行了多么精巧的设计,如果不能被创建,就如同韩信不能做将军,孙膑不能当军师,勾践不能回越国,刘备不能得荆州,一切一切的雄才武略都如废纸一张。既然“创建”对于对象如此重要,我们就来好好探讨一下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
- 浏览 5561
- 评论(9)
- 论坛回复 / 浏览 (9 / 6188)
- 查看更多
相关推荐
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 ...
VS集成C#开发ABB机器人二次开发:实时变量刷新与程序修改上位机系统,vs对ABB机器人二次开发C#集成PC SDK开发ABB机器人上位机开发 变量实时刷新,实时修改 io刷新修改, 在线程序修改实时刷新 上位机移动机械手 ,vs;ABB机器人二次开发;C#集成PC SDK;实时刷新;实时修改;io刷新修改;在线程序修改;上位机移动机械手,C#集成PC SDK开发ABB机器人上位机系统:实时刷新与修改功能
分布式系统与SCADA系统
,电机控制资料-- 注:本驱动器适合于直流有感无刷电机 功能特点 支持电压9V~36V,额定输出电流5A 支持电位器、开关、0~3.3V模拟信号范围、0 3.3 5 24V逻辑电平、PWM 频率 脉冲信号、RS485多种输入信号 支持占空比调速(调压)、速度闭环控制(稳速)、电流控制(稳流)多种调速方式 支持按键控制正反转速度,启停 特色功能 1. 霍尔自学习 电机的三相线和三霍尔信号线可不按顺序连接,驱动器可自动对电机霍尔顺序进行学习。 2. 稳速控制响应时间短 稳速控制时电机由正转2000RPM切为反转2000RPM,用时约1.0s,电机切过程平稳 3. 极低速稳速控制 电机进行极低速稳速控制,电机稳速控制均匀,无忽快忽慢现象。
欧姆龙CX-Programmer CP系列PLC功能块详解:伺服、步进、气缸及普通电机控制应用解析,欧姆龙cx-programmer CP系列PLC做的功能块,包括伺服,步进,气缸普通电机的控制。 ,欧姆龙CX-Programmer; CP系列PLC; 伺服控制; 步进控制; 电机控制; 气缸控制,欧姆龙CX-Programmer PLC:CP系列功能块与多种电机控制
基于comsol电弧与熔池热物理交互现象的研究,comsol电弧熔池耦合 ,comsol; 电弧熔池; 耦合,COMSOL电弧与熔池的耦合技术
,自动泊车APA开发,超声波算法开发
nodejs010-nodejs-config-chain-1.1.8-2.el6.centos.alt.noarch.rpm
FLAC3D蠕变命令流详解:博格斯本构模型的时间步长自动调整实践与应用,附图一至图三竖向位移云图变化及图四拱顶沉降趋势分析。,flac3d蠕变命令流,蠕变本构模型采用博格斯本构,时间步长自动调整,5.0和6.0命令均有,配有文字和视频解释。 图一至图三为不同蠕变时间下的竖向位移云图,图四为拱顶沉降随时间的变化趋势。 ,flac3d;蠕变命令流;博格斯本构;时间步长自动调整;5.0和6.0命令;文字解释;视频解释;竖向位移云图;拱顶沉降随时间变化趋势。,FLAC3D蠕变命令流:博格斯本构自动调整时间步长解释
免费JAVA毕业设计 2024成品源码+论文+数据库+启动教程 启动教程:https://www.bilibili.com/video/BV1SzbFe7EGZ 项目讲解视频:https://www.bilibili.com/video/BV1Tb421n72S 二次开发教程:https://www.bilibili.com/video/BV18i421i7Dx
超导电机性能及波形特征分析,某超导电机性能及其波形 ,超导电机性能; 波形; 性能指标; 波形分析,超导电机性能与波形分析
逆磁致伸缩效应:应变与磁导率互变之效应解析,逆磁致伸缩效应,应变造成磁导率改变 ,逆磁致伸缩效应; 磁导率变化; 应变影响; 磁性材料响应,逆磁致伸缩效应:磁导率随应变变化
基于VS2015+Qt5.9+Halcon20的多个相机缺陷检测源码,可稳定运行并支持多种相机缺陷检测功能,多个相机缺陷检测源码 vs2015+qt5.9+halcon20 可正常运行 ,多个相机;缺陷检测;源码;VS2015;Qt5.9;Halcon20;可正常运行,"Halcon源码检测系统,基于VS2015与Qt5.9,相机缺陷检测"
内容概要:本文旨在作为GitHub平台针对初学者的实用教程,涵盖从GitHub账号注册、仓库创建、代码管理、提交以及团队协作等全过程。文章详述了GitHub的基础使用方法,包括如何创建和配置代码仓库、使用Git命令进行代码的上传和变更处理、参与到开源项目的步骤,以及创建团队和管理权限的方式。还介绍了几个重要的Git命令及其作用,有助于用户理解版本控制系统的核心思想。通过这些指导,能够使开发者更快地适应这一流行工具,从而提升编码效率,提高协作效能。此外,也推荐使用者多多练习并投身实际操作,以此来累积更多的使用技巧。 适用人群:面向所有初次接触或正在初步探索GitHub使用方法的新用户,无论是独立工作者还是软件工程专业的学生均能从中受益。 使用场景及目标:主要目的是为了让新手能迅速熟悉并掌握GitHub的各项基本技能,以便更好地应用于日常的代码开发过程中。无论你是想要将自己的作品分享出来获取反馈,或是加入某个开源社区贡献自己的一份力量,本文都能提供完整的路径指引。 其他说明:虽然本指南涵盖了GitHub最常用的特性介绍,但对于高级设置及更复杂的用例则有所省略,若想深入了解相关进阶知识点,请参阅官方文档或者进一步研究其他权威资料。
deepseek部署教程.md
"Comsol电力变压器内部热源计算与热流耦合分析模型:温度场与流体场数值计算方法研究",comsol电力变压器温度场和流体场数值计算模型,通过变压器电磁场计算得到热源大小,最后通过热流耦合计算得到变压器内部温度场和流体场分布, ,核心关键词:Comsol模型; 电力变压器; 温度场; 流体场; 数值计算; 电磁场计算; 热流耦合计算; 内部温度场分布; 流体场分布。,"电力变压器温度场与流体场数值计算模型研究"
免费JAVA毕业设计 2024成品源码+论文+数据库+启动教程 启动教程:https://www.bilibili.com/video/BV1SzbFe7EGZ 项目讲解视频:https://www.bilibili.com/video/BV1Tb421n72S 二次开发教程:https://www.bilibili.com/video/BV18i421i7Dx
1、文件内容:publican-redhat-2.7-6.el7.rpm以及相关依赖 2、文件形式:tar.gz压缩包 3、安装指令: #Step1、解压 tar -zxvf /mnt/data/output/publican-redhat-2.7-6.el7.tar.gz #Step2、进入解压后的目录,执行安装 sudo rpm -ivh *.rpm 4、安装指导:私信博主,全程指导安装