阅读全文 »

11.5 最佳实践

再次说明,在使用建造者模式的时候考虑一下模板方法模式,别孤立地思考一个模式, 僵化地套用一个模式会让你受害无穷!

如果你已经看懂本书举的例子,并认可这种建造者模式,那你就放心使用,比单独使用建造者高效、简洁得多。

11.4 建造者模式的扩展

已经不用扩展了,因为我们在汽车模型制造的例子中已经对建造者模式进行了扩展,引入了模板方法模式。可能大家会比较疑惑,为什么在其他介绍设计模式的书籍上创建者模式并不是这样说的?读者请注意,建造者模式中还有一个角色没有说明,就是零件,建造者怎么去建造一个对象?是零件的组装,组装顺序不同对象效能也不同,这才是建造者模式要表达的核心意义,而怎么才能更好地达到这种效果呢?引入模板方法模式是一个非常简单而有效的办法。

大家看到这里估计就开始犯嘀咕了,这个建造者模式和工厂模式非常相似呀,是的,非常相似,但是记住一点你就可以游刃有余地使用了:建造者模式最主要的功能是基本方法的调用顺序安排,也就是这些基本方法已经实现了,通俗地说就是零件的装配,顺序不同产生的对象也不同;而工厂方法则重点是创建,创建零件是它的主要职责,组装顺序则不是它关心的。

11.3 建造者模式的应用

11.3.1 建造者模式的优点

  • 封装性

使用建造者模式可以使客户端不必知道产品内部组成的细节,如例子中我们就不需要关心每一个具体的模型内部是如何实现的,产生的对象类型就是CarModel。

  • 建造者独立,容易扩展

BenzBuilder和BMWBuilder是相互独立的,对系统的扩展非常有利。

  • 便于控制细节风险

由于具体的建造者是独立的,因此可以对建造过程逐步细化,而不对其他的模块产生任何影响。

11.3.2 建造者模式的使用场景

  • 相同的方法,不同的执行顺序,产生不同的事件结果时,可以采用建造者模式。
  • 多个部件或零件,都可以装配到一个对象中,但是产生的运行结果又不相同时,则可以使用该模式。
  • 产品类非常复杂,或者产品类中的调用顺序不同产生了不同的效能,这个时候使用建造者模式非常合适。
  • 在对象创建过程中会使用到系统中的一些其他对象,这些对象在产品对象的创建过程中不易得到时,也可以采用建造者模式封装该对象的创建过程。该种场景只能是一个补偿方法,因为一个对象不容易获得,而在设计阶段竟然没有发觉,而要通过创建者模式柔化创建过程,本身已经违反设计的最初目标。

11.3.3 建造者模式的注意事项

建造者模式关注的是零件类型和装配工艺(顺序),这是它与工厂方法模式最大不同的地方,虽然同为创建类模式,但是注重点不同。

建造者模式(Builder Pattern)也叫做生成器模式,其定义如下:

Separate the construction of a complex object from its representation so that the same construction process can create different representations.(将一个复杂对象的构建与它的表示分离,使得同样的构建过程可以创建不同的表示。)

建造者模式的通用类图如图11-4所示。

image-20210928154822516

图11-4 建造者模式通用类图
在建造者模式中,有如下4个角色: - Product产品类

通常是实现了模板方法模式,也就是有模板方法和基本方法,这个参考第10章的模板方法模式。例子中的BenzModel和BMWModel就属于产品类。

  • Builder抽象建造者

规范产品的组建,一般是由子类实现。例子中的CarBuilder就属于抽象建造者。

  • ConcreteBuilder具体建造者

实现抽象类定义的所有方法,并且返回一个组建好的对象。例子中的BenzBuilder和BMWBuilder就属于具体建造者。

  • Director导演类

负责安排已有模块的顺序,然后告诉Builder开始建造,在上面的例子中就是我们的老大,××公司找到老大,说我要这个或那个类型的车辆模型,然后老大就把命令传递给我,我和我的团队就开始拼命地建造,于是一个项目建设完毕了。

建造者模式的通用源代码也比较简单,先看Product类,通常它是一个组合或继承(如模板方法模式)产生的类,如代码清单11-12所示。

代码清单11-12 产品类

1
2
3
4
5
public class Product {
public void doSomething(){
//独立业务处理
}
}

抽象建造者如代码清单11-13所示

代码清单11-13 抽象建造者

1
2
3
4
5
6
public abstract class Builder {
//设置产品的不同部分,以获得不同的产品
public abstract void setPart();
//建造产品
public abstract Product buildProduct();
}

其中,setPart方法是零件的配置,什么是零件?其他的对象,获得一个不同零件,或者不同的装配顺序就可能产生不同的产品。具体的建造者如代码清单11-14所示。

代码清单11-14 具体建造者

1
2
3
4
5
6
7
8
9
10
public class ConcreteProduct extends Builder {
private Product product = new Product();
//设置产品零件
public void setPart(){
/** 产品类内的逻辑处理 */ }
//组建一个产品
public Product buildProduct() {
return product;
}
}

需要注意的是,如果有多个产品类就有几个具体的建造者,而且这多个产品类具有相同接口或抽象类,参考我们上面的例子。

导演类如代码清单11-15所示。

代码清单11-15 导演类

1
2
3
4
5
6
7
8
9
public class Director {
private Builder builder = new ConcreteProduct();
//构建不同的产品public
Product getAProduct(){
builder.setPart();
/** 设置不同的零件,产生不同的产品 */
return builder.buildProduct();
}
}

导演类起到封装的作用,避免高层模块深入到建造者内部的实现类。当然,在建造者模式比较庞大时,导演类可以有多个。

11.1 变化是永恒的

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

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

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

image-20210928153317200

图11-1 汽车模型类图

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

代码清单11-1 车辆模型的抽象类

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
public abstract class CarModel {
//这个参数是各个基本方法执行的顺序
private ArrayList<String> sequence = new ArrayList<String>();
//模型是启动开始跑了
protected abstract void start();
//能发动,还要能停下来,那才是真本事
protected abstract void stop();
//喇叭会出声音,是滴滴叫,还是哔哔叫
protected abstract void alarm();
//引擎会轰隆隆地响,不响那是假的
protected abstract void engineBoom();
//那模型应该会跑吧,别管是人推的,还是电力驱动,总之要会跑
final public void run() {
//循环一边,谁在前,就先执行谁
for(int i=0;i<this.sequence.size();i++){
String actionName = this.sequence.get(i);
if(actionName.equalsIgnoreCase("start")){
this.start();
//启动汽车
}
else if(actionName.equalsIgnoreCase("stop")){
this.stop();
//停止汽车
}
else if(actionName.equalsIgnoreCase("alarm")){
this.alarm();
//喇叭开始叫了
}
else if(actionName.equalsIgnoreCase("engine boom")){
//如果是engine
boom关键字 this.engineBoom();
//引擎开始轰鸣
}
}
}
//把传递过来的值传递到类内
final public void setSequence(ArrayList sequence){
this.sequence = sequence;
}
}

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

两个实现类分别实现父类的基本方法,奔驰模型如代码清单11-2所示。

代码清单11-2 奔驰模型代码

1
2
3
4
5
6
7
8
9
10
11
12
13
14
public class BenzModel extends CarModel {
protected void alarm() {
System.out.println("奔驰车的喇叭声音是这个样子的...");
}
protected void engineBoom() {
System.out.println("奔驰车的引擎是这个声音的...");
}
protected void start() {
System.out.println("奔驰车跑起来是这个样子的...");
}
protected void stop() {
System.out.println("奔驰车应该这样停车...");
}
}

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

代码清单11-3 宝马模型代码

1
2
3
4
5
6
7
8
9
10
11
12
13
14
public class BMWModel extends CarModel {
protected void alarm() {
System.out.println("宝马车的喇叭声音是这个样子的...");
}
protected void engineBoom() {
System.out.println("宝马车的引擎是这个声音的...");
}
protected void start() {
System.out.println("宝马车跑起来是这个样子的...");
}
protected void stop() {
System.out.println("宝马车应该这样停车...");
}
}

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

代码清单11-4 奔驰模型代码

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
public class Client {
public static void main(String[] args) {
/** 客户告诉XX公司,我要这样一个模型,然后XX公司就告诉我老大
* 说要这样一个模型,这样一个顺序,然后我就来制造
*/
BenzModel benz = new BenzModel();
//存放run的顺序
ArrayList<String> sequence = new ArrayList<String>();
sequence.add("engine boom");
//客户要求,run的时候先发动引擎
sequence.add("start");
//启动起来
sequence.add("stop");
//开了一段就停下来
//我们把这个顺序赋予奔驰车
benz.setSequence(sequence);
benz.run();
}
}

运行结果如下所示:

1
2
3
奔驰车的引擎是这个声音的... 
奔驰车跑起来是这个样子的...
奔驰车应该这样停车...

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

image-20210928153726353

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

代码清单11-5 抽象汽车组装者

1
2
3
4
5
6
public abstract class CarBuilder {
//建造一个模型,你要给我一个顺序要求,就是组装顺序
public abstract void setSequence(ArrayList<String> sequence);
//设置完毕顺序后,就可以直接拿到这个车辆模型
public abstract CarModel getCarModel();
}

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

代码清单11-6 奔驰车组装者

1
2
3
4
5
6
7
8
9
public class BenzBuilder extends CarBuilder {
private BenzModel benz = new BenzModel();
public CarModel getCarModel() {
return this.benz;
}
public void setSequence(ArrayList<String> sequence) {
this.benz.setSequence(sequence);
}
}

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

代码清单11-7 宝马车组装者

1
2
3
4
5
6
7
8
9
public class BMWBuilder extends CarBuilder {
private BMWModel bmw = new BMWModel();
public CarModel getCarModel() {
return this.bmw;
}
public void setSequence(ArrayList<String> sequence) {
this.bmw.setSequence(sequence);
}
}

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

代码清单11-8 修改后的场景类

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
public class Client {
public static void main(String[] args) {
/** 客户告诉XX公司,我要这样一个模型,然后XX公司就告诉我老大
* 说要这样一个模型,这样一个顺序,然后我就来制造
*/
//存放run的顺序
ArrayList<String> sequence = new ArrayList<String>();
sequence.add("engine boom");
//客户要求,run时候时候先发动引擎
sequence.add("start");
//启动起来
sequence.add("stop");
//开了一段就停下来
//要一个奔驰车:
BenzBuilder benzBuilder = new BenzBuilder();

//把顺序给这个builder类,制造出这样一个车出来
benzBuilder.setSequence(sequence);
//制造出一个奔驰车
BenzModel benz = (BenzModel)benzBuilder.getCarModel();
//奔驰车跑一下看看
benz.run();
}
}

运行结果如下所示:

1
2
3
奔驰车的引擎是这个声音的... 
奔驰车跑起来是这个样子的...
奔驰车应该这样停车...

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

代码清单11-9 相同顺序的宝马车的场景类

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
public class Client {
public static void main(String[] args) {
//存放run的顺序
ArrayList<String> sequence = new ArrayList<String>();
sequence.add("engine boom");
//客户要求,run的时候先发动引擎
sequence.add("start");
//启动起来
sequence.add("stop");
//开了一段就停下来
//要一个奔驰车:
BenzBuilder benzBuilder = new BenzBuilder();
//把顺序给这个builder类,制造出这样一个车出来
benzBuilder.setSequence(sequence);
//制造出一个奔驰车
BenzModel benz = (BenzModel)benzBuilder.getCarModel();
//奔驰车跑一下看看
benz.run();
//按照同样的顺序,我再要一个宝马
BMWBuilder bmwBuilder = new BMWBuilder();
bmwBuilder.setSequence(sequence);
BMWModel bmw = (BMWModel)bmwBuilder.getCarModel();
bmw.run();
}
}

运行结果如下所示:

1
2
3
4
5
6
奔驰车的引擎是这个声音的... 
奔驰车跑起来是这个样子的...
奔驰车应该这样停车...
宝马车的引擎是这个声音的...
宝马车跑起来是这个样子的...
宝马车应该这样停车...

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

image-20210928154319193

图11-3 完整汽车模型类图

类图看着复杂了,但还是比较简单,我们增加了一个Director类,负责按照指定的顺序生产模型,其中方法说明如下:

  • getABenzModel方法

组建出A型号的奔驰车辆模型,其过程为只有启动(start)、停止(stop)方法,其他的引擎声音、喇叭都没有。

  • getBBenzModel方法

组建出B型号的奔驰车,其过程为先发动引擎(engine boom),然后启动,再然后停车,没有喇叭。

  • getCBMWModel方法

组建出C型号的宝马车,其过程为先喇叭叫一下(alarm),然后启动,再然后是停车, 引擎不轰鸣。

  • getDBMWModel方法

组建出D型号的宝马车,其过程就一个启动,然后一路跑到黑,永动机,没有停止方法,没有喇叭,没有引擎轰鸣。

其他的E型号、F型号……可以有很多,启动、停止、喇叭、引擎轰鸣这4个方法在这个类中可以随意地自由组合。Director类如代码清单11-10所示。

代码清单11-10 导演类

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
public class Director {
private ArrayList<String> sequence = new ArrayList();
private BenzBuilder benzBuilder = new BenzBuilder();
private BMWBuilder bmwBuilder = new BMWBuilder();
/** A类型的奔驰车模型,先start,然后stop,其他什么引擎、喇叭一概没有 */
public BenzModel getABenzModel(){
//清理场景,这里是一些初级程序员不注意的地方
this.sequence.clear();
//ABenzModel的执行顺序
this.sequence.add("start");
this.sequence.add("stop");
//按照顺序返回一个奔驰车
this.benzBuilder.setSequence(this.sequence);
return (BenzModel)this.benzBuilder.getCarModel();
}
/** B型号的奔驰车模型,是先发动引擎,然后启动,然后停止,没有喇叭 */
public BenzModel getBBenzModel(){
this.sequence.clear();
this.sequence.add("engine boom");
this.sequence.add("start");
this.sequence.add("stop");

this.benzBuilder.setSequence(this.sequence);
return (BenzModel)this.benzBuilder.getCarModel();
}
/** C型号的宝马车是先按下喇叭(炫耀嘛),然后启动,然后停止 */
public BMWModel getCBMWModel(){
this.sequence.clear();
this.sequence.add("alarm");
this.sequence.add("start");
this.sequence.add("stop");
this.bmwBuilder.setSequence(this.sequence);
return (BMWModel)this.bmwBuilder.getCarModel();
}
/** D类型的宝马车只有一个功能,就是跑,启动起来就跑,永远不停止 */
public BMWModel getDBMWModel(){
this.sequence.clear();
this.sequence.add("start");
this.bmwBuilder.setSequence(this.sequence);
return (BMWModel)this.benzBuilder.getCarModel();
}
/** 这里还可以有很多方法,你可以先停止,然后再启动,或者一直停着不动,静态的嘛
* 导演类嘛,按照什么顺序是导演说了算
*/
}

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


注意 上面每个方法都有一个this.sequence.clear(),估计你一看就明白。但是作为一个系统分析师或是技术经理一定要告诉项目成员,ArrayList和HashMap如果定义成类的成员变 量,那你在方法中的调用一定要做一个clear的动作,以防止数据混乱。如果你发生过一次类似问题的话,比如ArrayList中出现一个“出乎意料”的数据,而你又花费了几个通宵才解决这 个问题,那你会有很深刻的印象。


有了这样一个导演类后,我们的场景类就更容易处理了,××公司要A类型的奔驰车1万辆,B类型的奔驰车100万辆,C类型的宝马车1000万辆,D类型的不需要,非常容易处理, 如代码清单11-11所示。

代码清单11-11 导演类

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
public class Client {
public static void main(String[] args) {
Director director = new Director();
//1万辆A类型的奔驰车
for(int i=0;i<10000;i++){
director.getABenzModel().run();
}
//100万辆B类型的奔驰车
for(int i=0;i<1000000;i++){
director.getBBenzModel().run();
}
//1000万辆C类型的宝马车
for(int i=0;i<10000000;i++){
director.getCBMWModel().run();
}
}
}

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

10.5 最佳实践

初级程序员在写程序的时候经常会问高手“父类怎么调用子类的方法”。这个问题很有普遍性,反正我是被问过好几回,那么父类是否可以调用子类的方法呢?我的回答是能,但强烈地、极度地不建议这么做,那该怎么做呢?

  • 把子类传递到父类的有参构造中,然后调用。
  • 使用反射的方式调用,你使用了反射还有谁不能调用的?!
  • 父类调用子类的静态方法。

这三种都是父类直接调用子类的方法,好用不?好用!解决问题了吗?解决了!项目中允许使用不?不允许!我就一直没有搞懂为什么要用父类调用子类的方法。如果一定要调用子类,那为什么要继承它呢?搞不懂。其实这个问题可以换个角度去理解,父类建立框架, 子类在重写了父类部分的方法后,再调用从父类继承的方法,产生不同的结果(而这正是模板方法模式)。这是不是也可以理解为父类调用了子类的方法呢?你修改了子类,影响了父类行为的结果,曲线救国的方式实现了父类依赖子类的场景,模板方法模式就是这种效果。

模板方法在一些开源框架中应用非常多,它提供了一个抽象类,然后开源框架写了一堆子类。在《××× In Action》中就说明了,如果你需要扩展功能,可以继承这个抽象类,然后覆写protected方法,再然后就是调用一个类似execute方法,就完成你的扩展开发,非常容易扩展的一种模式

10.4 模板方法模式的扩展

到目前为止,这两个模型都稳定地运行,突然有一天,老大急匆匆地找到了我:

“看你怎么设计的,车子一启动,喇叭就狂响,吵死人了!客户提出H1型号的悍马喇叭想让它响就响,H2型号的喇叭不要有声音,赶快修改一下。”

自己惹的祸,就要想办法解决它,稍稍思考一下,解决办法有了,先画出类图,如图10-4所示。

image-20210928152314427

图10-4 扩展悍马车模类图

类图改动似乎很小,在抽象类HummerModel中增加了一个实现方法isAlarm,确定各个型号的悍马是否需要声音,由各个实现类覆写该方法,同时其他的基本方法由于不需要对外提供访问,因此也设计为protected类型。其源代码如代码清单10-9所示。

代码清单10-9 扩展后的抽象模板类

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
public abstract class HummerModel {
/** 首先,这个模型要能够被发动起来,别管是手摇发动,还是电力发动,反正
* 是要能够发动起来,那这个实现要在实现类里了
*/
protected abstract void start();
//能发动,还要能停下来,那才是真本事
protected abstract void stop();
//喇叭会出声音,是滴滴叫,还是哔哔叫
protected abstract void alarm();
//引擎会轰隆隆的响,不响那是假的
protected abstract void engineBoom();
//那模型应该会跑吧,别管是人推的,还是电力驱动,总之要会跑
final public void run() {
//先发动汽车
this.start();
//引擎开始轰鸣
this.engineBoom();
//要让它叫的就是就叫,喇嘛不想让它响就不响
if(this.isAlarm()){
this.alarm();
}
//到达目的地就停车
this.stop();
}
//钩子方法,默认喇叭是会响的
protected boolean isAlarm(){
return true;
}
}

在抽象类中,isAlarm是一个实现方法。其作用是模板方法根据其返回值决定是否要响喇叭,子类可以覆写该返回值,由于H1型号的喇叭是想让它响就响,不想让它响就不响, 由人控制,其源代码如代码清单10-10所示。

代码清单10-10 扩展后的H1悍马

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
public class HummerH1Model extends HummerModel {
private boolean alarmFlag = true;
//要响喇叭
protected void alarm() {
System.out.println("悍马H1鸣笛...");
}
protected void engineBoom() {
System.out.println("悍马H1引擎声音是这样的...");
}
protected void start() {
System.out.println("悍马H1发动...");
}

protected void stop() {
System.out.println("悍马H1停车...");
}
protected boolean isAlarm() {
return this.alarmFlag;
}
//要不要响喇叭,是由客户来决定的
public void setAlarm(boolean isAlarm){
this.alarmFlag = isAlarm;
}
}

只要调用H1型号的悍马,默认是有喇叭响的,当然你可以不让喇叭响,通过isAlarm(false)就可以实现。H2型号的悍马是没有喇叭声响的,其源代码如代码清单10-11所示。

代码清单10-11 扩展后的H2悍马

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
public class HummerH2Model extends HummerModel {
protected void alarm() {
System.out.println("悍马H2鸣笛...");
}
protected void engineBoom() {
System.out.println("悍马H2引擎声音是这样的...");
}
protected void start() {
System.out.println("悍马H2发动...");
}
protected void stop() {
System.out.println("悍马H2停车...");
}
//默认没有喇叭的
protected boolean isAlarm() {
return false;
}
}

H2型号的悍马设置isAlarm()的返回值为false,也就是关闭了喇叭功能。场景类代码如代码清单10-12所示。

代码清单10-12 扩展后的场景类

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
public class Client {
public static void main(String[] args) throws IOException {
System.out.println("-------H1型号悍马--------");
System.out.println("H1型号的悍马是否需要喇叭声响?0-不需要 1-需要");
String type=(new BufferedReader(new InputStreamReader(System.in))).readLine();
HummerH1Model h1 = new HummerH1Model();

if(type.equals("0")){
h1.setAlarm(false);
}
h1.run();
System.out.println("\n-------H2型号悍马--------");
HummerH2Model h2 = new HummerH2Model();
h2.run();
}
}

运行是需要交互的,首先,要求输入H1型号的悍马是否有声音,如下所示:

1
2
-------H1型号悍马-------- 
H1型号的悍马是否需要喇叭声响?0-不需要 1-需要

输入“0”后的运行结果如下所示:

1
2
3
4
5
6
7
8
9
10
-------H1型号悍马-------- 
H1型号的悍马是否需要喇叭声响?0-不需要 1-需要
0
悍马H1发动...
悍马H1引擎声音是这样的...
悍马H1停车...
-------H2型号悍马--------
悍马H2发动...
悍马H2引擎声音是这样的...
悍马H2停车...

输入“1”后的运行结果如下所示:

1
2
3
4
5
6
7
8
9
10
11
-------H1型号悍马-------- 
H1型号的悍马是否需要喇叭声响?0-不需要 1-需要
1
悍马H1发动...
悍马H1引擎声音是这样的...
悍马H1鸣笛...
悍马H1停车...
-------H2型号悍马--------
悍马H2发动...
悍马H2引擎声音是这样的...
悍马H2停车...

看到没,H1型号的悍马是由客户自己控制是否要响喇叭,也就是说外界条件改变,影响到模板方法的执行。在我们的抽象类中isAlarm的返回值就是影响了模板方法的执行结果,该方法就叫做钩子方法(Hook Method)。有了钩子方法模板方法模式才算完美,大家可以想想,由子类的一个方法返回值决定公共部分的执行结果,是不是很有吸引力呀!

模板方法模式就是在模板方法中按照一定的规则和顺序调用基本方法,具体到前面那个例子,就是run()方法按照规定的顺序(先调用start(),然后再调用engineBoom(),再调用alarm(),最后调用stop())调用本类的其他方法,并且由isAlarm()方法的返回值确定run()中的执行顺序变更。

10.3 模板方法模式的应用

10.3.1 模板方法模式的优点

  • 封装不变部分,扩展可变部分

把认为是不变部分的算法封装到父类实现,而可变部分的则可以通过继承来继续扩展。 在悍马模型例子中,是不是就非常容易扩展?例如增加一个H3型号的悍马模型,很容易呀,增加一个子类,实现父类的基本方法就可以了。

  • 提取公共部分代码,便于维护

我们例子中刚刚走过的弯路就是最好的证明,如果我们不抽取到父类中,任由这种散乱的代码发生,想想后果是什么样子?维护人员为了修正一个缺陷,需要到处查找类似的代码!

  • 行为由父类控制,子类实现

基本方法是由子类实现的,因此子类可以通过扩展的方式增加相应的功能,符合开闭原则。

10.3.2 模板方法模式的缺点

按照我们的设计习惯,抽象类负责声明最抽象、最一般的事物属性和方法,实现类完成具体的事物属性和方法。但是模板方法模式却颠倒了,抽象类定义了部分抽象方法,由子类实现,子类执行的结果影响了父类的结果,也就是子类对父类产生了影响,这在复杂的项目中,会带来代码阅读的难度,而且也会让新手产生不适感。

10.3.3 模板方法模式的使用场景

  • 多个子类有公有的方法,并且逻辑基本相同时。
  • 重要、复杂的算法,可以把核心算法设计为模板方法,周边的相关细节功能则由各个子类实现。
  • 重构时,模板方法模式是一个经常使用的模式,把相同的代码抽取到父类中,然后通过钩子函数(见“模板方法模式的扩展”)约束其行为。

10.2 模板方法模式的定义

模板方法模式(Template Method Pattern)是如此简单,以致让你感觉你已经能够掌握其精髓了。其定义如下:

Define the skeleton of an algorithm in an operation,deferring some steps to subclasses.Template Method lets subclasses redefine certain steps of an algorithm without changing the algorithm’s structure.(定义一个操作中的算法的框架,而将一些步骤延迟到子类中。使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤。)

模板方法模式的通用类图如图10-3所示。

image-20210928151457541

图10-3 修改后的悍马车模类图
模板方法模式确实非常简单,仅仅使用了Java的继承机制,但它是一个应用非常广泛的模式。其中,AbstractClass叫做抽象模板,它的方法分为两类: - 基本方法

基本方法也叫做基本操作,是由子类实现的方法,并且在模板方法被调用。

  • 模板方法

可以有一个或几个,一般是一个具体方法,也就是一个框架,实现对基本方法的调度, 完成固定的逻辑。


注意 为了防止恶意的操作,一般模板方法都加上final关键字,不允许被覆写。


在类图中还有一个角色:具体模板。ConcreteClass1和ConcreteClass2属于具体模板,实现父类所定义的一个或多个抽象方法,也就是父类定义的基本方法在子类中得以实现。

我们来看其通用代码,AbstractClass如代码清单10-6所示。

代码清单10-6 抽象模板类

1
2
3
4
5
6
7
8
9
10
11
public abstract class AbstractClass {
//基本方法
protected abstract void doSomething();
//基本方法
protected abstract void doAnything();
//模板方法
public void templateMethod(){
/** 调用基本方法,完成相关的逻辑 */ this.doAnything();
this.doSomething();
}
}

具体模板如代码清单10-7所示。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
public class ConcreteClass1 extends AbstractClass {
//实现基本方法
protected void doAnything() {
//业务逻辑处理
}
protected void doSomething() {
//业务逻辑处理
}
}
public class ConcreteClass2 extends AbstractClass {

//实现基本方法
protected void doAnything() {
//业务逻辑处理
}
protected void doSomething() {
//业务逻辑处理
}
}

场景类如代码清单10-8所示。

代码清单10-8 场景类

1
2
3
4
5
6
7
8
9
public class Client {
public static void main(String[] args) {
AbstractClass class1 = new ConcreteClass1();
AbstractClass class2 = new ConcreteClass2();
//调用模板方法
class1.templateMethod();
class2.templateMethod();
}
}

注意 抽象模板中的基本方法尽量设计为protected类型,符合迪米特法则,不需要暴露 的属性或方法尽量不要设置为protected类型。实现类若非必要,尽量不要扩大父类中的访问 权限。