焦点讯息:这样来理解设计模式,你绝对可以

楼下小黑GG   2023-01-10 16:03:38

设计模式之建造者模式


【资料图】

变化是永恒的

又是一个周三,快要下班了,老大突然拉住我,喜滋滋地告诉我:“××公司很满意我们 做的模型,又签订了一个合同,把奔驰、宝马的车辆模型都交给我们公司制作了,不过这次 又额外增加了一个新需求:汽车的启动、停止、喇叭声音、引擎声音都由客户自己控制,他 想什么顺序就什么顺序,这个没问题吧?”

那任务又是一个时间紧、工程量大的项目,为什么是“又”呢?因为基本上每个项目都是 如此,我该怎么来完成这个任务呢?

首先,我们分析一下需求,奔驰、宝马都是一个产品,它们有共有的属性,××公司关心 的是单个模型的运行过程:奔驰模型A是先有引擎声音,然后再响喇叭;奔驰模型B是先启 动起来,然后再有引擎声音,这才是××公司要关心的。那到我们老大这边呢,就是满足人家 的要求,要什么顺序就立马能产生什么顺序的模型出来。我就负责把老大的要求实现出来, 而且还要是批量的,也就是说××公司下单订购宝马A车模,我们老大马上就找我“生产一个 这样的车模,启动完毕后,喇叭响一下”,然后我们就准备开始批量生产这些模型。由我生 产出N多个奔驰和宝马车辆模型,这些车辆模型都有run()方法,但是具体到每一个模型的 run()方法中间的执行任务的顺序是不同的,老大说要啥顺序,我就给啥顺序,最终客户买走 后只能是既定的模型。好,需求还是比较复杂,我们先一个一个地解决,先从找一个最简单 的切入点——产品类,每个车都是一个产品,如图11-1所示。

类图比较简单,在CarModel中我们定义了一个setSequence方法,车辆模型的这几个动作 要如何排布,是在这个ArrayList中定义的。然后run()方法根据sequence定义的顺序完成指定 的顺序动作,与第10章介绍的模板方法模式是不是非常类似?好,我们先看CarModel源代 码,如代码清单11-1所示。代码清单11-1 车辆模型的抽象类

CarModel的设计原理是这样的,setSequence方法是允许客户自己设置一个顺序,是要先 启动响一下喇叭再跑起来,还是要先响一下喇叭再启动。对于一个具体的模型永远都固定 的,但是对N多个模型就是动态的了。在子类中实现父类的基本方法,run()方法读取 sequence,然后遍历sequence中的字符串,哪个字符串在先,就先执行哪个方法。两个实现类分别实现父类的基本方法,奔驰模型如代码清单11-2所示。 代码清单11-2 奔驰模型代码

宝马车模型如代码清单11-3所示。 代码清单11-3 宝马模型代码

两个产品的实现类都完成,我们来模拟一下××公司的要求:生产一个奔驰模型,要求跑 的时候,先发动引擎,然后再挂挡启动,然后停下来,不需要喇叭。这个需求很容易满足, 我们增加一个场景类实现该需求,如代码清单11-4所示。代码清单11-4 奔驰模型代码

运行结果如下所示:

看,我们组装了这样的一辆汽车,满足了××公司的需求。但是想想我们的需求,汽车的动作执行顺序是要能够随意调整的。我们只满足了一个需求,还有下一个需求呀,然后是第 二个宝马模型,只要启动、停止,其他的什么都不要;第三个模型,先喇叭,然后启动,然 后停止;第四个......直到把你逼疯为止,那怎么办?我们就一个一个地来写场景类满足吗? 不可能了,那我们要想办法来解决这个问题,有了!我们为每种模型产品模型定义一个建造 者,你要啥顺序直接告诉建造者,由建造者来建造,于是乎我们就有了如图11-2所示的类 图。

增加了一个CarBuilder抽象类,由它来组装各个车模,要什么类型什么顺序的车辆模型,都由相关的子类完成。首先编写CarBuilder代码,如代码清单11-5所示。 代码清单11-5 抽象汽车组装者

很简单,每个车辆模型都要有确定的运行顺序,然后才能返回一个车辆模型。奔驰车的组装者如代码清单11-6所示。 代码清单11-6 奔驰车组装者

非常简单实用的程序,给定一个汽车的运行顺序,然后就返回一个奔驰车,简单了很 多。宝马车的组装与此相同,如代码清单11-7所示。代码清单11-7 宝马车组装者

两个组装者都完成了,我们再来看看××公司的需求如何满足,修改一下场景类,如代码 清单11-8所示。代码清单11-8 修改后的场景类

运行结果如下所示:

那如果我再想要个同样顺序的宝马车呢?很简单,再次修改一下场景类,如代码清单 11-9所示。代码清单11-9 相同顺序的宝马车的场景类

运行结果如下所示:

看,同样运行顺序的宝马车也生产出来了,而且代码是不是比刚开始直接访问产品类 (Procuct)简单了很多。我们在做项目时,经常会有一个共识:需求是无底洞,是无理性 的,不可能你告诉它不增加需求就不增加,这4个过程(start、stop、alarm、engine boom)按 照排列组合有很多种,××公司可以随意组合,它要什么顺序的车模我就必须生成什么顺序的 车模,客户可是上帝!那我们不可能预知他们要什么顺序的模型呀,怎么办?封装一下,找 一个导演,指挥各个事件的先后顺序,然后为每种顺序指定一个代码,你说一种我们立刻就 给你生产处理,好方法,厉害!我们先修改一下类图,如图11-3所示。

类图看着复杂了,但还是比较简单,我们增加了一个Director类,负责按照指定的顺序生产模型,其中方法说明如下:● getABenzModel方法组建出A型号的奔驰车辆模型,其过程为只有启动(start)、停止(stop)方法,其他的 引擎声音、喇叭都没有。● getBBenzModel方法组建出B型号的奔驰车,其过程为先发动引擎(engine boom),然后启动,再然后停 车,没有喇叭。● getCBMWModel方法 组建出C型号的宝马车,其过程为先喇叭叫一下(alarm),然后启动,再然后是停车,引擎不轰鸣。● getDBMWModel方法组建出D型号的宝马车,其过程就一个启动,然后一路跑到黑,永动机,没有停止方 法,没有喇叭,没有引擎轰鸣。其他的E型号、F型号......可以有很多,启动、停止、喇叭、引擎轰鸣这4个方法在这个 类中可以随意地自由组合。Director类如代码清单11-10所示。代码清单11-10 导演类

顺便说一下,大家看一下程序中有很多this调用。这个我一般是这样要求项目组成员 的,如果你要调用类中的成员变量或方法,需要在前面加上this关键字,不加也能正常地跑 起来,但是不清晰,加上this关键字,我就是要调用本类中的成员变量或方法,而不是本方 法中的一个变量。还有super方法也是一样,是调用父类的成员变量或者方法,那就加上这个 关键字,不要省略,这要靠约束,还有就是程序员的自觉性,他要是死不悔改,那咱也没 招。

注意 上面每个方法都有一个this.sequence.clear(),估计你一看就明白。但是作为一个 系统分析师或是技术经理一定要告诉项目成员,ArrayList和HashMap如果定义成类的成员变 量,那你在方法中的调用一定要做一个clear的动作,以防止数据混乱。如果你发生过一次类 似问题的话,比如ArrayList中出现一个“出乎意料”的数据,而你又花费了几个通宵才解决这 个问题,那你会有很深刻的印象。有了这样一个导演类后,我们的场景类就更容易处理了,××公司要A类型的奔驰车1万 辆,B类型的奔驰车100万辆,C类型的宝马车1000万辆,D类型的不需要,非常容易处理, 如代码清单11-11所示。代码清单11-11 导演类

清晰、简单吧,我们写程序重构的最终目的就是:简单、清晰。代码是让人看的,不是 写完就完事了,我一直在教育我带的团队成员,Java程序不是像我们前辈写二进制代码、汇 编一样,写完基本上就自己能看懂,别人看就跟看天书一样,现在的高级语言,要像写中文 汉字一样,你写的,别人能看懂。这就是建造者模式。

摘自:作者 秦小波《设计模式之禅》 侵权删

想要更深层次兴趣性学习可以来北!大!课!

工!场

推荐