建造者模式理解

定义

定义虽然基本没有屌用，因为大部分人都看不懂，但是还的说出来。。。

The intent of the Builder design pattern is to separate the
construction of a complex object from its representation. By doing so
the same construction process can create different representations.
将一个复杂对象的构建与其表示分离，使得同样的构建过程可以创建不同的表示

使用场景

这个就非常重要了，因为如果你学了个东西，都不知道用来解决什么问题，你说有什么用？理解使用场景的的重要性要远高于你是不是会实现这个模式，因为只要你知道什么问题可以使用builder模式来解决，那你即使不会写，（知道思想比死记代码重要）也可以在调查相关资料后完成。 我不想说一些大而正确的术语来把你搞蒙，我们只针对具体的问题，至于延展性的思考，随着你知识的增长，逐渐会明白的

当一个类的构造函数参数个数超过4个，而且这些参数有些是可选的参数，考虑使用构造者模式。
可能看到这你感觉和你学的建造者模式不太一样，别着急继续看

解决的问题

当一个类的构造函数参数超过4个，而且这些参数有些是可选的时，我们通常有两种办法来构建它的对象。 例如我们现在有如下一个类计算机类Computer，其中cpu与ram是必填参数，而其他3个是可选参数，那么我们如何构造这个类的实例呢,通常有两种常用的方式：

public class Computer {
    private String cpu;//必须
    private String ram;//必须
    private int usbCount;//可选
    private String keyboard;//可选
    private String display;//可选
}

第一：折叠构造函数模式（telescoping constructor pattern ），这个我们经常用,如下代码所示

public class Computer {
     ...
    public Computer(String cpu, String ram) {
        this(cpu, ram, 0);
    }
    public Computer(String cpu, String ram, int usbCount) {
        this(cpu, ram, usbCount, "罗技键盘");
    }
    public Computer(String cpu, String ram, int usbCount, String keyboard) {
        this(cpu, ram, usbCount, keyboard, "三星显示器");
    }
    public Computer(String cpu, String ram, int usbCount, String keyboard, String display) {
        this.cpu = cpu;
        this.ram = ram;
        this.usbCount = usbCount;
        this.keyboard = keyboard;
        this.display = display;
    }
}

第二种：Javabean 模式（get set），如下所示

public class Computer {
        ...
    public String getCpu() {
        return cpu;
    }
    public void setCpu(String cpu) {
        this.cpu = cpu;
    }
    public String getRam() {
        return ram;
    }
    public void setRam(String ram) {
        this.ram = ram;
    }
    public int getUsbCount() {
        return usbCount;
    }
...
}

为了解决这两个痛点，builder模式就横空出世了

第一种主要是使用及阅读不方便。你可以想象一下，当你要调用一个类的构造函数时，你首先要决定使用哪一个，然后里面又是一堆参数，如果这些参数的类型很多又都一样，你还要搞清楚这些参数的含义，很容易就传混了。。。那酸爽谁用谁知道。(有次写公司项目的测试类一个对象12个参数，爽死我了)

第二种方式在构建过程中对象的状态容易发生变化，造成错误。因为那个类中的属性是分步设置的，所以就容易出错。（一直set看着也不舒服）

为了解决这两个痛点，builder模式就横空出世了。（当初我刚看到就被这个方式征服了）

如何实现

1. 在Computer 中创建一个静态内部类 Builder，然后将Computer 中的参数都复制到Builder类中。
2. 在Computer中创建一个private的构造函数，参数为Builder类型
3. 在Builder中创建一个public的构造函数，参数为Computer中必填的那些参数，cpu 和ram。
4. 在Builder中创建设置函数，对Computer中那些可选参数进行赋值，返回值为Builder类型的实例
5. 在Builder中创建一个build()方法，在其中构建Computer的实例并返回

下面代码就是最终的样子(高能时刻)

public class Computer {
    private final String cpu;//必须
    private final String ram;//必须
    private final int usbCount;//可选
    private final String keyboard;//可选
    private final String display;//可选

    private Computer(Builder builder){
        this.cpu=builder.cpu;
        this.ram=builder.ram;
        this.usbCount=builder.usbCount;
        this.keyboard=builder.keyboard;
        this.display=builder.display;
    }
    public static class Builder{
        private String cpu;//必须
        private String ram;//必须
        private int usbCount;//可选
        private String keyboard;//可选
        private String display;//可选

        public Builder(String cup,String ram){
            this.cpu=cup;
            this.ram=ram;
        }

        public Builder setUsbCount(int usbCount) {
            this.usbCount = usbCount;
            return this;
        }
        public Builder setKeyboard(String keyboard) {
            this.keyboard = keyboard;
            return this;
        }
        public Builder setDisplay(String display) {
            this.display = display;
            return this;
        }        
        public Computer build(){
            return new Computer(this);
        }
    }
  //省略getter方法
}

如何使用

在客户端使用链式调用，一步一步的把对象构建出来。

Computer computer=new Computer.Builder("因特尔","三星")
                .setDisplay("三星24寸")
                .setKeyboard("罗技")
                .setUsbCount(2)
                .build();

个人吐槽点

这种感觉爽不爽？有没有配置springSecurity的感觉 （springSecurity 的HttpSecurity也是典型的建造者模式有兴趣可以了解一下）

看到这个图可能感觉少了一个角色 少了director 这个角色，将构建算法交给了client
上面的代码也是，都不是传统的建造者模式。这里先简单提一下后面说明。

案例

构建者模式是一个非常实用而常见的创建类型的模式（creational design pattern)，例如图片处理框架Glide，网络请求框架Retrofit等都使用了此模式。

经典的来了

其实上面的内容是Builder在Java中一种简化的使用方式，经典的Builder 模式与其有一定的不同，如果没有兴趣的同学就可以不用往下读了。（后面的彩蛋可能就看不见了）

传统Builder 模式

uml类图

如上图所示，builder模式有4个角色。

• Product: 最终要生成的对象，例如 Computer实例。
• Builder：
  构建者的抽象基类（有时会使用接口代替）。其定义了构建Product的抽象步骤，其实体类需要实现这些步骤。其会包含一个用来返回最终产品的方法Product
  getProduct()。
• ConcreteBuilder: Builder的实现类
• Director: 决定如何构建最终产品的算法. 其会包含一个负责组装的方法void Construct(Builder
  builder)， 在这个方法中通过调用builder的方法，就可以设置builder，等设置完成后，就可以通过builder的
  getProduct() 方法获得最终的产品。

这个时候就有杠精说了你不是画了5个角色吗 ？ client是为了一会讲解上面提到的少了director 这个角色的问题好表示一些
我们接下来将最开始的例子使用传统方式来实现一遍。

第一步：我们的目标Computer类：

public class Computer {
    private String cpu;//必须
    private String ram;//必须
    private int usbCount;//可选
    private String keyboard;//可选
    private String display;//可选

    public Computer(String cpu, String ram) {
        this.cpu = cpu;
        this.ram = ram;
    }
    public void setUsbCount(int usbCount) {
        this.usbCount = usbCount;
    }
    public void setKeyboard(String keyboard) {
        this.keyboard = keyboard;
    }
    public void setDisplay(String display) {
        this.display = display;
    }
    @Override
    public String toString() {
        return "Computer{" +
                "cpu='" + cpu + '\'' +
                ", ram='" + ram + '\'' +
                ", usbCount=" + usbCount +
                ", keyboard='" + keyboard + '\'' +
                ", display='" + display + '\'' +
                '}';
    }
}

第二步：抽象构建者类

public abstract class ComputerBuilder {
    public abstract void setUsbCount();
    public abstract void setKeyboard();
    public abstract void setDisplay();
    public abstract Computer getComputer();
}

第三步：实体构建者类，我们可以根据要构建的产品种类产生多了实体构建者类，这里我们需要构建两种品牌的电脑，苹果电脑和联想电脑，所以我们生成了两个实体构建者类。

苹果电脑构建者类

public class MacComputerBuilder extends ComputerBuilder {
    private Computer computer;
    public MacComputerBuilder(String cpu, String ram) {
        computer = new Computer(cpu, ram);
    }
    @Override
    public void setUsbCount() {
        computer.setUsbCount(2);
    }
    @Override
    public void setKeyboard() {
        computer.setKeyboard("苹果键盘");
    }
    @Override
    public void setDisplay() {
        computer.setDisplay("苹果显示器");
    }
    @Override
    public Computer getComputer() {
        return computer;
    }
}

联想电脑构建者类

public class LenovoComputerBuilder extends ComputerBuilder {
    private Computer computer;
    public LenovoComputerBuilder(String cpu, String ram) {
        computer=new Computer(cpu,ram);
    }
    @Override
    public void setUsbCount() {
        computer.setUsbCount(4);
    }
    @Override
    public void setKeyboard() {
        computer.setKeyboard("联想键盘");
    }
    @Override
    public void setDisplay() {
        computer.setDisplay("联想显示器");
    }
    @Override
    public Computer getComputer() {
        return computer;
    }
}

第四步：指导者类（Director）

public class ComputerDirector {
    public void makeComputer(ComputerBuilder builder){
        builder.setUsbCount();
        builder.setDisplay();
        builder.setKeyboard();
    }
}

使用

首先生成一个director (1)，然后生成一个目标builder (2)，接着使用director组装builder (3),组装完毕后使用builder创建产品实例 (4)。

public static void main(String[] args) {
        ComputerDirector director=new ComputerDirector();//1
        ComputerBuilder builder=new MacComputerBuilder("I5处理器","三星125");//2
        director.makeComputer(builder);//3
        Computer macComputer=builder.getComputer();//4
        System.out.println("mac computer:"+macComputer.toString());

        ComputerBuilder lenovoBuilder=new LenovoComputerBuilder("I7处理器","海力士222");
        director.makeComputer(lenovoBuilder);
        Computer lenovoComputer=lenovoBuilder.getComputer();
        System.out.println("lenovo computer:"+lenovoComputer.toString());
}

输出结果如下：

mac computer:Computer{cpu='I5处理器', ram='三星125', usbCount=2, keyboard='苹果键盘', display='苹果显示器'}
lenovo computer:Computer{cpu='I7处理器', ram='海力士222', usbCount=4, keyboard='联想键盘', display='联想显示器'}

感觉到两个代码的区别的吧
这就我被第一个案例代码征服的原因

可以看到，文章最开始的使用方式是传统builder模式的变种， 首先其省略了director 这个角色，将构建算法交给了client端，其次将builder 写到了要构建的产品类里面，最后采用了链式调用。

优点:

建造者模式的封装性很好。使用建造者模式可以有效的封装变化，在使用建造者模式的场景中，一般产品类和建造者类是比较稳定的，因此，将主要的业务逻辑封装在指挥者类中对整体而言可以取得比较好的稳定性。

在建造者模式中，客户端不必知道产品内部组成的细节，将产品本身与产品的创建过程解耦使得相同的创建过程可以创建不同的产品对象。

可以更加精细地控制产品的创建过程。将复杂产品的创建步骤分解在不同的方法中，使得仓建过程更加清晰，也更方便使用程序来控制创建过程。

建造者模式很容易进行扩展。如果有新的需求，通过实现一个新的建造者类就可以完成，基本上不用修改之前已经测试通过的代码，因此也就不会对原有功能引入风险。符合开闭原则。

缺点:

造者模式所创建的产品一般具有较多的共同点，其组成部分相似，如果产品之间的差异性很大，则不适合使用建造者模式，因此其使用范围受到一定的限制。

看到上面基本的建造者模式已经讲完了但是挖的坑还没有解决

再回答之前再看一个案例

StringBuilder类

uml 类图

看到这是不是更不理解了，director 没有就算了 ，产品类都没有了 （手动滑稽 ） 大都知道产品类是string
而client端充当的是director 角色
其实当你查看Java的源码时会发现好多的建造者模式里都是没有写出固定的director 角色全是客户端充当的director 角色，我是这样理解的 当你如果把director写死的时候，我们在使用时灵活性不好，当client端充当的是director 角色时我问可以按照自己的想法拼装出想要的类

比如 你要买一杯珍珠奶茶
标准的流程是：（我猜的）

1.  拿杯子
2.  加珍珠
3.  加冰
4.  加奶茶
5.  封口

突然你今天不想冰的了给服务员说：“我要去冰的 ”
服务员：流程是固定的不可以改变（这不就尴尬了）
如果采用客户端控制的话 在其他默认的情况下她会问你 几分糖，加不加冰，大杯小杯，加不加其他的东西

传统代码

产品类

public class MilkTea {//奶茶
    private  String type;//口味
    private  String size;//杯子大小
    private  boolean pearl;//是否加珍珠
    private  boolean ice;//是否加冰

    public MilkTea() {
    }

    public MilkTea(String type, String size, boolean pearl, boolean ice) {
        this.type = type;
        this.size = size;
        this.pearl = pearl;
        this.ice = ice;
    }

    public String getType() {
        return type;
    }

    public void setType(String type) {
        this.type = type;
    }

    public String getSize() {
        return size;
    }

    public void setSize(String size) {
        this.size = size;
    }

    public boolean isPearl() {
        return pearl;
    }

    public void setPearl(boolean pearl) {
        this.pearl = pearl;
    }

    public boolean isIce() {
        return ice;
    }

    public void setIce(boolean ice) {
        this.ice = ice;
    }

    @Override
    public String toString() {
        return "MilkTea{" +
                "type='" + type + '\'' +
                ", size='" + size + '\'' +
                ", pearl=" + pearl +
                ", ice=" + ice +
                '}';
    }
}

抽象构建者类

public interface MilkTeaBuilder {
    public abstract void setType();//设置口味
    public abstract void setSize();//大小
    public abstract void setPearl();//是否加珍珠
    public abstract void setIce();//加冰
    public abstract MilkTea getMilkTea();//出奶茶
}

实体构建者类

public class PearlMilkBuilder implements MilkTeaBuilder {//加冰原味珍珠奶茶
    private MilkTea milkTea=new MilkTea();
    @Override
    public void setType() {
        this.milkTea.setType("原味");

    }

    @Override
    public void setSize() {
        this.milkTea.setSize("大杯");

    }

    @Override
    public void setPearl() {
        this.milkTea.setPearl(true);
    }

    @Override
    public void setIce() {
        this.milkTea.setIce(true);
    }
    @Override
    public MilkTea getMilkTea() {
        return this.milkTea;
    }
}

指导者类

public class MilkDirector {
    public  MilkTea makeDirector(MilkTeaBuilder milkTeaBuilder)//指导者类  奶茶的创建顺序是写死的
    {
        milkTeaBuilder.setType();
        milkTeaBuilder.setSize();
        milkTeaBuilder.setPearl();
        milkTeaBuilder.setIce();
        return milkTeaBuilder.getMilkTea();
    }
}

没有指导者类的代码

public class MilkTeaPlus {
    private final String type;
    private final String size;
    private final boolean pearl;
    private final boolean ice;

    private MilkTeaPlus(Builder builder) {
        this.type = builder.type;
        this.size = builder.size;
        this.pearl = builder.pearl;
        this.ice = builder.ice;
    }

    public String getType() {
        return type;
    }

    public String getSize() {
        return size;
    }

    public boolean isPear1() {
        return pearl;
    }

    public boolean isIce() {
        return ice;
    }

    public static class Builder {
        private final String type;
        private String size = "中杯";
        private boolean pearl = true;
        private boolean ice = false;

        public Builder(String type) {
            this.type = type;
        }

        public Builder size(String size) {
            this.size = size;
            return this;
        }

        public Builder pear1(boolean pearl) {
            this.pearl = pearl;
            return this;
        }

        public Builder ice(boolean cold) {
            this.ice = cold;
            return this;
        }

        public MilkTeaPlus build() {
            return new MilkTeaPlus(this);
        }
    }

    @Override
    public String toString() {
        return "MilkTeaPlus{" +
                "type='" + type + '\'' +
                ", size='" + size + '\'' +
                ", pearl=" + pearl +
                ", ice=" + ice +
                '}';
    }
}

测试类

public class Foodie {
    public static void main(String[] args) {
        //传统的构建者模式
        //买珍珠奶茶
        MilkDirector milkDirector = new MilkDirector();
        PearlMilkBuilder pearlMilkBuilder = new PearlMilkBuilder();
        MilkTea milkTea = milkDirector.makeDirector(pearlMilkBuilder);
        System.out.println(milkTea.toString());
        //今天肚子疼不想和加冰的
        PearlMilkBuilder pearlMilkBuilder1 = new PearlMilkBuilder();
        MilkTea milkTea1 = milkDirector.makeDirector(pearlMilkBuilder);
        System.out.println(milkTea1.toString());
        MilkTeaPlus build = new MilkTeaPlus.Builder("草莓味").size("大杯").ice(false).pear1(false).build();
        System.out.println(build.toString());


    }
}

测试结果