每天学习一个设计模式(九):创建型之建造者模式

目录

一、基本概念

二、通俗解释

三、建造者模式详解

1.造车的例子

2.建造者模式的结构

3.建造者模式的优点

4.使用场景

5.注意事项

四、建造者模式的扩展和最佳实践

建造者模式的扩展

最佳实践


一、基本概念

建造者模式(Builder Pattern)也叫做生成器模式,其定义如下:Separate the construction of a complex object from its representation so that the same constructionprocess can create different representations.(将一个复杂对象的构建与它的表示分离,使得同样的构建过程可以创建不同的表示。)

二、通俗解释

BUILDER建造者模式:MM最爱听的就是“我爱你”这句话了,见到不同地方的MM,要能够用她们的方言跟她说这句话哦,我有一个多种语言翻译机,上面每种语言都有一个按键,见到MM我只要按对应的键,它就能够用相应的语言说出“我爱你”这句话了,国外的MM也可以轻松搞掂,这就是我的“我爱你”builder。(这一定比美军在伊拉克用的翻译机好卖) 建造模式:将产品的内部表象和产品的生成过程分割开来,从而使一个建造过程生成具有不同的内部表象的产品对象。建造模式使得产品内部表象可以独立的变化,客户不必知道产品内部组成的细节。建造模式可以强制实行一种分步骤进行的建造过程。

产品的内部表象

一个产品常有不同的组成成分作为产品的零件,这些零件有可能是对象,也有可能不是对象,它们通常又叫做产品的内部表象(internal representation)。不同的产品可以有不同的内部表象,也就是不同的零件。使用建造模式可以使客户端不需要知道所生成的产品有哪些零件,每个产品的对应零件彼此有何不同,是怎么建造出来的,以及怎么组成产品。

三、建造者模式详解

1.造车的例子

又是一个周三,快要下班了,老大突然拉住我,喜滋滋地告诉我:“××公司很满意我们做的模型,又签订了一个合同,把奔驰、宝马的车辆模型都交给我们公司制作了,不过这次又额外增加了一个新需求:汽车的启动、停止、喇叭声音、引擎声音都由客户自己控制,他想什么顺序就什么顺序,这个没问题吧?”那任务又是一个时间紧、工程量大的项目,为什么是“又”呢?因为基本上每个项目都是如此,我该怎么来完成这个任务呢?

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

每天学习一个设计模式(九):创建型之建造者模式_第1张图片

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

车辆模型的抽象类

public abstract class CarModel {
    /**
     * 各个基本方法的执行顺序
     */
    private ArrayList sequence = new ArrayList<>();

    /**
     * 模型启动开始跑了
     */
    abstract void start();

    /**
     * 能发动,还要能停下来,那才是真本事
     */
    abstract void stop();

    /**
     * 喇叭会出声音,是滴滴叫,还是哔哔叫
     */
    abstract void alarm();

    /**
     * 引擎会轰隆轰地响,不响那是假的
     */
    abstract void engineBoom();

    /**
     * 是车都会跑吧,别管是人推的,还是电动的,总之要会跑
     */
    final public void run(){
        //循环一遍,谁在前,就先执行谁
        for (String actionName : this.sequence) {
            switch (actionName) {
                case "start":
                    this.start();
                    break;
                case "stop":
                    this.stop();
                    break;
                case "alarm":
                    this.alarm();
                    break;
                case "engine boom":
                    this.engineBoom();
                    break;
                default:
                    break;
            }
        }
    }

    /**
     * 把传递过来的值传递到类里面
     * @param sequence
     */
    final public void setSequence(ArrayList sequence){
        this.sequence = sequence;
    }
}

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

两个实现类分别实现父类的基本方法。

奔弛模型类

public class BenzModel extends CarModel {
    @Override
    void start() {
        System.out.println("奔弛跑起来是这样子的。。。");
    }

    @Override
    void stop() {
        System.out.println("奔弛应该是这样停车的。。。");
    }

    @Override
    void alarm() {
        System.out.println("奔弛的喇叭声音是这样的。。。");
    }

    @Override
    void engineBoom() {
        System.out.println("奔弛的引擎声音是这样的。。。");
    }
}

宝马模型类

public class BMWModel extends CarModel {
    @Override
    void start() {
        System.out.println("宝马跑起来是这样子的。。。");
    }

    @Override
    void stop() {
        System.out.println("宝马应该是这样停车的。。。");
    }

    @Override
    void alarm() {
        System.out.println("宝马的喇叭声音是这样的。。。");
    }

    @Override
    void engineBoom() {
        System.out.println("宝马的引擎声音是这样的。。。");
    }
}

两个产品的实现类都完成,我们来模拟一下××公司的要求:生产一个奔驰模型,要求跑的时候,先发动引擎,然后再挂挡启动,然后停下来,不需要喇叭。这个需求很容易满足,我们增加一个客户端类实现该需求。

public class Client {
    public static void main(String[] args) {
        //客户告诉XX公司,我要这样一个模型,然后XX公司就告诉我老大
        //说要这样一个模型,这样一个顺序,然后我就来制造
        BenzModel benz = new BenzModel();
        //存放run的顺序
        ArrayList sequence = new ArrayList<>();
        sequence.add("engine boom");
        sequence.add("start");
        sequence.add("stop");
        benz.setSequence(sequence);
        benz.run();
    }
}

运行结果如下所示:

奔弛的引擎声音是这样的。。。
奔弛跑起来是这样子的。。。
奔弛应该是这样停车的。。。

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

每天学习一个设计模式(九):创建型之建造者模式_第2张图片

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

抽象汽车组装者

public abstract class CarBuilder {
    /**
     * 建造一个模型,你要给我一个顺序要求,就是组装顺序
     * @param sequence
     */
    public abstract void setSequence(ArrayList sequence);

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

很简单,每个车辆模型都要有确定的运行顺序,然后才能返回一个车辆模型。

奔驰车组装者类

public class BenzBuilder extends CarBuilder {
    private BenzModel benz = new BenzModel();
    @Override
    public void setSequence(ArrayList sequence) {
        this.benz.setSequence(sequence);
    }

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

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

宝马车组装者类

public class BMWBuilder extends CarBuilder {
    private BMWModel bmw = new BMWModel();
    @Override
    public void setSequence(ArrayList sequence) {
        this.bmw.setSequence(sequence);
    }

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

两个组装者都完成了,我们再来看看××公司的需求如何满足,修改一下客户端类。

修改后的客户端类

public class Client {
    public static void main(String[] args) {
        //客户告诉XX公司,我要这样一个模型,然后XX公司就告诉我老大
        //说要这样一个模型,这样一个顺序,然后我就来制造
        //存放run的顺序
        ArrayList sequence = new ArrayList<>();
        sequence.add("engine boom");
        sequence.add("start");
        sequence.add("stop");
        BenzBuilder benzBuilder = new BenzBuilder();
        benzBuilder.setSequence(sequence);
        BenzModel benz = (BenzModel) benzBuilder.getCarModel();
        benz.run();
    }
}

运行结果如下所示:

奔弛的引擎声音是这样的。。。
奔弛跑起来是这样子的。。。
奔弛应该是这样停车的。。。

那如果我再想要个同样顺序的宝马车呢?很简单,再次修改一下客户端类。

相同顺序的宝马车的客户端类

public class Client {
    public static void main(String[] args) {
        //客户告诉XX公司,我要这样一个模型,然后XX公司就告诉我老大
        //说要这样一个模型,这样一个顺序,然后我就来制造
        //存放run的顺序
        ArrayList sequence = new ArrayList<>();
        sequence.add("engine boom");
        sequence.add("start");
        sequence.add("stop");
        //建造一个奔弛
        BenzBuilder benzBuilder = new BenzBuilder();
        benzBuilder.setSequence(sequence);
        BenzModel benz = (BenzModel) benzBuilder.getCarModel();
        benz.run();
        //按照相同顺序,再建造一个宝马
        BMWBuilder bmwBuilder = new BMWBuilder();
        bmwBuilder.setSequence(sequence);
        BMWModel bmw = (BMWModel) bmwBuilder.getCarModel();
        bmw.run();
    }
}

运行结果如下所示:

奔弛的引擎声音是这样的。。。
奔弛跑起来是这样子的。。。
奔弛应该是这样停车的。。。
宝马的引擎声音是这样的。。。
宝马跑起来是这样子的。。。
宝马应该是这样停车的。。。
 

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

每天学习一个设计模式(九):创建型之建造者模式_第3张图片

 

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

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

●getBBenzModel方法

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

●getCBMWModel方法

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

●getDBMWModel方法

组建出D型号的宝马车,其过程就一个启动,然后一路跑到黑,永动机,没有停止方法,没有喇叭,没有引擎轰鸣。其他的E型号、F型号……可以有很多,启动、停止、喇叭、引擎轰鸣这4个方法在这个类中可以随意地自由组合。

导演类

public class Director {
    private ArrayList sequence = new ArrayList<>();
    private BenzBuilder benzBuilder = new BenzBuilder();
    private BMWBuilder bmwBuilder = new BMWBuilder();

    /**
     * A类型奔弛
     * @return
     */
    public BenzModel getABenzModel(){
        this.sequence.clear();
        this.sequence.add("start");
        this.sequence.add("stop");
        this.benzBuilder.setSequence(this.sequence);
        return (BenzModel) this.benzBuilder.getCarModel();
    }

    /**
     * B类型奔弛
     * @return
     */
    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类型宝马
     * @return
     */
    public BMWModel getCBMWModel(){
        this.sequence.clear();
        this.sequence.add("alarm");
        this.sequence.add("start");
        this.sequence.add("stop");
        this.benzBuilder.setSequence(this.sequence);
        return (BMWModel) this.bmwBuilder.getCarModel();
    }

    /**
     * D类型宝马
     * @return
     */
    public BMWModel getDBMWModel(){
        this.sequence.clear();
        this.sequence.add("start");
        this.benzBuilder.setSequence(this.sequence);
        return (BMWModel) this.bmwBuilder.getCarModel();
    }
    //还可以有很多方法,导演说了算。。。
}

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

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

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

客户端类

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();
        }
        //建造10万辆B类型奔弛
        for (int i = 0; i < 100000; i++) {
            director.getBBenzModel().run();
        }
        //建造100万辆C类型宝马
        for (int i = 0; i < 1000000; i++) {
            director.getCBMWModel().run();
        }
        //建造1000万辆D类型宝马
        for (int i = 0; i < 10000000; i++) {
            director.getDBMWModel().run();
        }
    }
}

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

2.建造者模式的结构

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

每天学习一个设计模式(九):创建型之建造者模式_第4张图片

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

●Product产品类

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

●Builder抽象建造者

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

●ConcreteBuilder具体建造者

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

●Director导演类

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

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

public class Product{
    public void doSomething(){
        //独立业务处理
    }
}

抽象建造者

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

其中,setPart方法是零件的配置,什么是零件?其他的对象,获得一个不同零件,或者不同的装配顺序就可能产生不同的产品。

具体建造者

public class ConcreteProduct extends Builder{
    private Product product = new Product();
    //设置产品零件
    public void setPart(){
        //产品类内的逻辑处理
    }
    //组建一个产品
    public Product buildProduct(){
        return product;
    }
}

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

导演类

public class Director{
    private Builder builder = new ConcreteProduct();
    //建造不同的产品
    public Product getAProduct(){
        builder.setPart();
        //设置不同的零件,产生不同的产品
        return builder.buildProduct();
    }
}

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

3.建造者模式的优点

●  封装性

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

●  建造者独立,容易扩展

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

●  便于控制细节风险

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

4.使用场景

相同的方法,不同的执行顺序,产生不同的事件结果时,可以采用建造者模式。

多个部件或零件,都可以装配到一个对象中,但是产生的运行结果又不相同时,则可以使用该模式。

产品类非常复杂,或者产品类中的调用顺序不同产生了不同的效能,这个时候使用建造者模式非常合适。

在对象创建过程中会使用到系统中的一些其他对象,这些对象在产品对象的创建过程中不易得到时,也可以采用建造者模式封装该对象的创建过程。该种场景只能是一个补偿方法,因为一个对象不容易获得,而在设计阶段竟然没有发觉,而要通过创建者模式柔化创建过程,本身已经违反设计的最初目标。

5.注意事项

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

四、建造者模式的扩展和最佳实践

建造者模式的扩展

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

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

最佳实践

再次说明,在使用建造者模式的时候考虑一下模板方法模式,别孤立地思考一个模式,僵化地套用一个模式会让你受害无穷!如果你已经看懂本书举的例子,并认可这种建造者模式,那你就放心使用,比单独使用建造者高效、简洁得多。


参考秦小波的《设计模式之禅(第2版)》

你可能感兴趣的:(设计模式,java,设计模式,编程语言,python,php)