更新于 

Java设计模式之建造者模式

建造者模式(Builder Pattern)使用多个简单的对象一步一步构建成一个复杂的对象。这种类型的设计模式属于创建型模式,它提供了一种创建对象的最佳方式。

一个 Builder 类会一步一步构造最终的对象。该 Builder 类是独立于其他对象的。

介绍

意图:将一个复杂的构建与其表示相分离,使得同样的构建过程可以创建不同的表示。

主要解决:主要解决在软件系统中,有时候面临着”一个复杂对象”的创建工作,其通常由各个部分的子对象用一定的算法构成;由于需求的变化,这个复杂对象的各个部分经常面临着剧烈的变化,但是将它们组合在一起的算法却相对稳定。

何时使用:一些基本部件不会变,而其组合经常变化的时候。

如何解决:将变与不变分离开。

优点: 1、建造者独立,易扩展。 2、便于控制细节风险。

缺点: 1、产品必须有共同点,范围有限制。 2、如内部变化复杂,会有很多的建造类。

使用场景: 1、需要生成的对象具有复杂的内部结构。 2、需要生成的对象内部属性本身相互依赖。

注意事项:与工厂模式的区别是:建造者模式更加关注与零件装配的顺序。

变化是永恒的

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

又是一个时间紧、工作量大的任务。

首先分析一下需求,奔驰、宝马都是一个产品,它们有共有的属性××公司关心的是单个模型的运行过程:

  • 奔驰模型A是先有引擎声音,然后再响喇叭;
  • 奔驰模型B是先启动起来,然后再有引擎声音

这才是××公司要关心的。

要满足人家的要求,要什么顺序就立马能产生什么顺序的模型出来。要把这个要求实现出来,而且还要是批量的,也就是说××公司下单订购宝马A车模,需要马上就“生产一个这样的车模,启动完毕后,喇叭响一下”,然后我们就准备开始批量生产这些模型。

生产出N多个奔驰和宝马车辆模型,这些车辆模型都有run()方法,但是具体到每一个模型的run()方法中间的执行任务的顺序是不同的,要啥顺序,就给啥顺序,最终客户买走后只能是既定的模型。需求还是比较复杂,一个一个地解决,先找个简单的切入点——产品类,每个车都是一个产品。

产品类类图

image-20210624154822772

(图片取自《设计模式之禅》)

在CarModel中我们定义了一个setSequence方法,车辆模型的这几个动作要如何排布,是在这个ArrayList中定义的。然后run()方法根据sequence定义的顺序完成指定的顺序动作。

代码清单

车辆模型抽象类

CarModel.java
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 (String actionName : this.sequence) {
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;
}

}

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

代码清单:奔驰模型代码

BenzModel.java
public class BenzModel extends CarModel {

@Override
protected void start() {
System.out.println("奔驰车启动..");
}

@Override
protected void stop() {
System.out.println("奔驰车停止..");
}

@Override
protected void alarm() {
System.out.println("奔驰车的喇叭声音..");
}

@Override
protected void engineBoom() {
System.out.println("奔驰车的引擎声..");
}
}

代码清单:宝马车模型代码

BMWModel.java
public class BMWModel extends CarModel {

@Override
protected void start() {
System.out.println("宝马车启动..");
}

@Override
protected void stop() {
System.out.println("宝马车停止..");
}

@Override
protected void alarm() {
System.out.println("宝马车的喇叭声音..");
}

@Override
protected void engineBoom() {
System.out.println("宝马车的引擎声..");
}
}

模拟一下场景,生产一个奔驰车模型,要求跑的时候,先发动引擎,然后再挂挡启动,然后停下来,不需要喇叭。

代码清单

Client.java
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();
}

}

运行结果:

奔驰车的引擎声..
奔驰车启动..
奔驰车停止..

Process finished with exit code 0

通过这种方式,满足了客户的需求。

但是客户的需求是多变的,下一个需求可能要一个宝马模型,只要启动、停止,其他的什么都不要。第三个模型、第四个模型…

那就需要一个一个来写场景类满足这些需求,这显然是不实际的。

为每种模型产品模型定义一个建造者,你要啥顺序直接告诉建造者,由建造者来建造。

类图

image-20210624162305391

(图片取自《设计模式之禅》)

增加一个CarBuilder抽象类,由它来组装各个车模,要什么类型什么顺序的车辆模型,都由相关的子类完成。

代码清单:抽象代码组装者

CarBuilder.java
public abstract class CarBuilder {

//建造一个模型,你要给我一个顺序要求,就是组装顺序
public abstract void setSequence(ArrayList<String> sequence);

//设置完毕顺序后,就可以直接拿到这个车辆模型
public abstract CarModel getCarModel();

}

代码清单:奔驰车组装者

BenzBuilder.java
public class BenzBuilder extends CarBuilder{

private BenzModel benz = new BenzModel();

@Override
public void setSequence(ArrayList<String> sequence) {
this.benz.setSequence(sequence);
}

@Override
public CarModel getCarModel() {
return this.benz;
}
}

代码清单:宝马车组装者

BMWBuilder.java
public class BMWBuilder extends CarBuilder{

private BMWModel bmw = new BMWModel();

@Override
public void setSequence(ArrayList<String> sequence) {
this.bmw.setSequence(sequence);
}

@Override
public CarModel getCarModel() {
return this.bmw;
}
}

代码清单:修改后的场景类

Client.java
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();
}
}

运行结果:

奔驰车的引擎声..
奔驰车启动..
奔驰车停止..

Process finished with exit code 0

再来个宝马车模型。

代码清单:再次修改后的场景类

Client.java
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();
}
}

运行结果:

奔驰车的引擎声..
奔驰车启动..
奔驰车停止..
宝马车的引擎声..
宝马车启动..
宝马车停止..

Process finished with exit code 0

同样运行顺序的宝马车也生产出来了,而且代码是不是比刚开始直接访问产品类(Procuct)简单了很多。

在做项目时,经常会有一个共识:需求是无底洞,是无理性的,不可能你告诉它不增加需求就不增加,这4个过程(start、stop、alarm、engine boom)按照排列组合有很多种,××公司可以随意组合,它要什么顺序的车模我就必须生成什么顺序的车模,客户可是上帝!那我们不可能预知他们要什么顺序的模型呀,怎么办?封装一下,找一个导演,指挥各个事件的先后顺序,然后为每种顺序指定一个代码,你说一种我们立刻就给你生产处理。

类图

image-20210624170153863

(图片取自《设计模式之禅》)

增加了一个Director类,负责按照指定的顺序生产模型。

getABenzModel、getBBenzModel、getCBMWModel、getDBMWModel等方法表示生产不同需求的车辆模型的方法。

代码清单:导演类

Director.java
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();
}

}

代码清单:场景类

Client.java
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();
}
}
}

建造者模式的定义

Separate the construction of a complex object from its representation so that the same construction process can create different representations.

将一个复杂对象的构建与它的表示分离,使得同样的构建过程可以创建不同的表示。

建造者模式通用类图

image-20210624174216729

(图片取自《设计模式之禅》)

建造者模式种,有如下4个角色:

  • Product产品

    通常是实现了模板方法模式,也就是有模板方法和基本方法。

  • Builder抽象建造者

    规范产品的组建,一般是由子类实现。

  • ConcreteBuilder具体建造者

    实现抽象类定义的所有方法,并且返回一个组件好的对象。

  • Director导演类

    负责安排已有模块的顺序,然后告诉Builder开始建造。

建造者模式的应用

建造者模式的优点

  • 封装性

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

  • 建造者独立,容易扩展

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

  • 便于控制细节风险

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

建造者模式的使用场景

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

建造者模式的注意事项

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