开篇废话

周末因懒的原因，停更了两天。今天主要研究建造者模式。畅游各大博客网站，推荐一篇关于建造者模式的博客http://blog.csdn.net/self_study/article/details/51707029，简单明了，条例清晰。如果看不懂我写的，可以尝试去看看别人的。。。

什么是建造者模式

讲建造者模式，这里要提取几个关键词：

• 复杂对象： 这里简单的体现可以理解为，这里对象的成员数量很多，所以它很复杂。
• 构建过程： 对成员对象进行赋值，业务逻辑生成等一系列使之成为一个成熟的对象。
• 表示： 返回这个对象。
• 构建过程与表示分离： 一般来说，对成员对象的赋值通常在构造函数中，这种方式除了不够灵活之外，还有就是如果成员对象过多，因为构造函数就会显得十分臃肿。所以，我们可以将构建过程（简单的理解为赋值，这里不严谨，只是为了帮助理解概念）封装成独立的方法，然后再返回整个需要的实例对象。

那么建造者模式：就是为了解决生成复杂对象的问题，主要通过将构建过程与表示分离的方法。

如何实现建造者模式

理解了建造者模式后，我们来实现它，就相对简单了。
首先盗图一张：

建造者模式类图

可以看到，这里呈现了四个类，有时候实际开发中会将这个模型进行简化，我们这里先学习理论，因为实际操作时，灵活变动太多了，不适合讲解。但是万变不离其宗，核心思想就是这些。

• Product，都称这个为产品类，说白了就是我需要生成的类。
• Builder类，这是一个抽象类或者接口，用来规定构建对象的所需方法。
• ConcreteBuilder 对builder的抽象方法的实现类，通常对其优化为product的内部类，从而省掉builder的定义。常见的有 AlertDialog.Builder 。
• Director 调用concrete的方法的类。一般来说，使用的建造者模式时，这个也给省了。

我们先来看一个完整版的。以造汽车为例，现在我们需要一辆，有四个轮子，有四个座椅，有防风玻璃，有方向盘，发动机等等（这里只列举这几样）。

• 首先我们先看Product类，就是我们要生成的复杂对象，这里就是指小汽车。

public class Car {
    List<String> tyres = new ArrayList<>();
    List<String> carMounts = new ArrayList<>();
    String glass;
    String steeringWheel;
    String engine;

    public void setTyres(String tyres) {
        this.tyres.add(tyres);
    }

    public void setCarMounts(String carMounts) {
        this.carMounts.add(carMounts);
    }

    public void setGlass(String glass) {
        this.glass = glass;
    }

    public void setSteeringWheel(String steeringWheel) {
        this.steeringWheel = steeringWheel;
    }

    public void setEngine(String engine) {
        this.engine = engine;
    }

    public List<String> getTyres() {
        return tyres;
    }

    public List<String> getCarMounts() {
        return carMounts;
    }

    public String getGlass() {
        return glass;
    }

    public String getSteeringWheel() {
        return steeringWheel;
    }

    public String getEngine() {
        return engine;
    }

}

这里可以看到小汽车有五个属性，然后通过setter和getter方法来对属性赋值。

• 然后我们先看Builder类，这是一个抽象类或者接口，具体使用看情况而定，我今天想用接口表示：

public interface Builder {
    public void buildeTyre(int wheelNumber);
    public void buildCarMounts(int carMountsNumber);
    public void buildGalss();
    public void buildSteeringWheel();
    public void buildEngine();
    public Car build();
}

这里定义了五个造小汽车零件的方法，和一个生成对象方法，因为你不能只造这些零件，还需要把这些零件给组装起来啊。

• 紧接着我们需要ConcreteBuilder类来实现这些方法啊，毕竟我们是实干家，不能光说不做！concretebuilder

public class CarBuilder implements Builder {
    
    Car car = new  Car();
    @Override
    public void buildeTyre(int wheelNumber) {
        for (int i = 0; i < wheelNumber; i++) {
            car.setTyres("已经造了" + i + "轮子了");
        }
    }

    @Override
    public void buildCarMounts(int carMountsNumber) {
        for (int i = 0; i < carMountsNumber; i++) {
            car.setCarMounts("已经造了" + i + "椅子了");
        }
    }

    @Override
    public void buildGalss() {
        car.setGlass("防风玻璃做好了");
    }

    @Override
    public void buildSteeringWheel() {
        car.setSteeringWheel("方向盘做好了");
    }

    @Override
    public void buildEngine() {
        car.setEngine("发动机已经做好了");
    }

    @Override
    public Car build() {
        return car;
    }

}

这里实现了builder接口，没什么好说的，值得注意的就是，在CarBuilder类中，维护了一个Car对象，实现的所有方法中，去调用Car的set方法，最后build（）方法中去返回这个对象。
此时此刻，我们已经能通过CarBuilder类去建造我们所需要的Car对象了。但是毕竟造汽车的工序是及其复杂了，因为我们这里只简单的列举了五项，可能感觉还是比较轻松的，但是，如果有上百道工序的话，难道我们需要每次去造小车的时候都去调用这上百个方法吗。显然，这里构建的过程，我们希望是不透明的，那么我们可以将这个步骤封装起来，于是就有了Director类的出现。

• 我们希望有一个技术总工来调度负责整个造车的过程。

public class AodiDirecter {
    private Builder builder;

    public AodiDirecter(Builder builder) {
        this.builder = builder;
    }

    public void construct() {
        builder.buildeTyre(4);
        builder.buildCarMounts(4);
        builder.buildEngine();
        builder.buildGalss();
        builder.buildSteeringWheel();
    }
}

这样整个建造者模式就完成了，而我们需要一个奥迪车时，只需要：

public class Buyer {
    public void buy() {
        Builder builder = new CarBuilder();
        AodiDirecter director = new AodiDirecter(builder);
        director.construct();
        Car aodiCar = builder.build();
    }
}

如果说，builder是产线工人们，AodiDirecter 就可以理解为奥迪工程师，工人们只知道制造器件，工程师来统筹设计造车的工序，安排下去后，工人们按命令执行就行了。而对于买家来说，我并看不到你是怎么造的，反正我只要结果就行了。

但是这样往往会很麻烦，我们通常会对其进行精简优化。

看上面对建造者定义了四个功能模块，在实现过程中，是不是有一些，何必多此一举的感觉。这里我盗用了别人的代码，工作繁忙（太懒了）还请谅解。

public class Computer {
    private String CPU;
    private String GPU;
    private String memoryType;
    private int memorySize;
    private String storageType;
    private int storageSize;
    private String screenType;
    private float screenSize;
    private String OSType;

    public static class Builder {
        // Optional parameters - initialize with default values
        private String CPU = "inter-i3";
        private String GPU = "GTX-960";
        private String memoryType = "ddr3 1666MHz";
        private int memorySize = 8;//8GB
        private String storageType = "hdd";
        private int storageSize = 1024;//1TB
        private String screenType = "IPS";
        private float screenSize = 23.8f;
        private String OSType = "Windows 10";

        public Builder() {
        }

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

        public Builder setGPU(String GPU) {
            this.GPU = GPU;
            return this;
        }
        public Builder setMemoryType(String memoryType) {
            this.memoryType = memoryType;
            return this;
        }

        public Builder setMemorySize(int memorySize) {
            this.memorySize = memorySize;
            return this;
        }
        public Builder setStorageType(String storageType) {
            this.storageType = storageType;
            return this;
        }

        public Builder setStorageSize(int storageSize) {
            this.storageSize = storageSize;
            return this;
        }

        public Builder setScreenType(String screenType) {
            this.screenType = screenType;
            return this;
        }
        public Builder setScreenSize(float screenSize) {
            this.screenSize = screenSize;
            return this;
        }

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


        public Computer create() {
            return new Computer(this);
        }

    }

    private Computer(Builder builder) {
        CPU = builder.CPU;
        GPU = builder.GPU;
        memoryType = builder.memoryType;
        memorySize = builder.memorySize;
        storageType = builder.storageType;
        storageSize = builder.storageSize;
        screenType = builder.screenType;
        screenSize = builder.screenSize;
        OSType = builder.OSType;
    }
}

可以看到，整个建造者模式就是一个类，然而这个类中存在一个静态内部类Builder，这个Builder，其实对应的是建造者模式中的concreteBuilder，Computer对应的就是我们product。去掉了Builder抽象类，因为直接实现了。同时还缺少了Directer，因为这里的设计是暴露构建细节，所以就不需要了。
这种方式的好处就是，过程可控。我们来看看调用。

Computer computer = new Computer.Builder()
        .setCPU("inter-skylake-i7")
        .setGPU("GTX-Titan")
        .setMemoryType("ddr4-2133MHz")
        .setMemorySize(16)
        .setStorageType("ssd")
        .setStorageSize(512)
        .setScreenType("IPS")
        .setScreenSize(28)
        .setOSType("Ubuntu/Window10")
        .create();

这是一种链式调用，也是我们常见的建造者模式。我们可以对每个成员对象进行控制，从而得到我们想要的product。当然，我们看回Computer类的实现，发现，每个成员对象都是有个默认值的。也就是说，你完全可以通过new Computer.Builder().create()来获取默认的实例对象，这基本就是Directer的功能。所以精简下来，发现建造者模式还是挺实用的。
然而在大型的系统中，精简版的建造者模式，并不是很适用，因为它的针对性太强，往往呈现出来的是同一种产品，拓展性并不是很好，而我们使用原始版的话，可以对Directer进行拓展，可以更加多元灵活。