前言
建造者模式（Bulider Pattern）是将一个复杂对象的构建过程与它的实现表示分离，使得同样的构建过程可以创建不同的表示，属于创建型模式。使用创建者模式对于用户而言只需要制定需要建造的类就可以获得对象，建造过程及细节不需要了解。
概述
将一个复杂对象的构建与表示分离，使得同样的构建过程可以创建不同的表示。
Builder模式一步一步创建一个复杂的对象，它允许用户可以只通过指定复杂对象的类型和内容就可以构建它们。用户不知道内部的具体构建细节。Builder模式是非常类似抽象工厂模式。细微的差别大概只有在反复使用中才能体会到。
为何使用
是为了将构建复杂对象的过程和它的部件解耦。注意：是解耦过程和部件。因为一个复杂的对象，不但有很多大量组成部分，如汽车，有很多部件：车轮、方向盘、发动机还有各种小零件等等，部件很多，但远不止这些，如何将这些部件装配成一辆汽车，这个装配的过程也很复杂（需要很好的组装技术），Builder模式就是为了将部件和组装过程分开。
结构
- 抽象建造者类（Builder）：这个接口规定要实现复杂对象的那些部分的创建，并不涉及具体的部件对象的创建。
- 具体建造者类（ConcreteBuilder）：实现 Builder 接口，完成复杂产品的各个部件的具体创建方法。在构造过程完成后，提供产品的实例。
- 产品类（Product）：要创建的复杂对象。
- 指挥者类（Director）：调用具体建造者来创建复杂对象的各个部分，在指导者中不涉及具体产品的信息，只负责保证对象各部分完整创建或按某种顺序创建。
如何使用
首先假设一个复杂的对象是由多个组件组成的，Builder模式是把复杂对象的创建和部件的创建分别开来，分别用builder类和Director类来表示。
首先，需要一个接口，它定义如何创建复杂对象的各个部件：
public interface Builder{
//创建部件A 比如创建汽车车轮
void buildPartA();
//创建部件B 比如创建汽车方向盘
void buildPartB();
//创建部件B 比如创建汽车发动机
void buildPartB();
//返回最后组装成品结果（返回最后装配好的汽车）
//成品的组装过程不在这里进行，而是转移到下面的Director类中进行
//从而实现了解耦过程和部件
Product getResult();
}
用Director构建最后的复杂对象，而在上面Builder接口中封装的是如何创建一个个部件（复杂对象是由这些部件组成的），也就是说Director的内容是如何将部件最后组装成成品：
public class Director{
private Builder builder;
public Director(Builder builder){
this.builder = builder;
}
//将部件partA partB partC最后组成复杂对象
//这里是将车轮 方向盘和发动机组装成汽车的过程
public void construct(){
builder.buildPartA();
builder.buildPartB();
builder.buildPartC();
}
}
Builder的具体实现ConcreteBuilder:
通过具体完成接口Builder来构建或装配产品的部件
定义并明确它所要创建的是什么具体东西；
提供一个可以重新获取产品的接口；
public class ConcreteBuilder implements Builder{
Part partA,partB,partC;
public void buildPartA(){
//这里是具体如何场景partA的代码
}
public void buildPartB(){
//这里是具体如何场景partA的代码
}
public void buildPartC(){
//这里是具体如何场景partA的代码
}
pubic Product getResult(){
//返回最后组装成品结果
}
}
复杂对象：产品Product:
public interface Product{}
复杂对象的部件：
public interface Part{}
我们看看如何调用Builder模式：
ConcreteBuilder builder = new ConcreteBuilder();
Director director = new Director(builder);
director.construct();
Product product = builder.getResult();
优缺点
优点：
建造者模式的封装性很好。使用建造者模式可以有效的封装变化，在使用建造者模式的场景中，一般产品类和建造者类是比较稳定的，因此，将主要的业务逻辑封装在指挥者类中对整体而言可以取得比较好的稳定性。
在建造者模式中，客户端不必知道产品内部组成的细节，将产品本身与产品的创建过程解耦，使得相同的创建过程可以创建不同的产品对象。
可以更加精细地控制产品的创建过程 。将复杂产品的创建步骤分解在不同的方法中，使得创建过程更加清晰，也更方便使用程序来控制创建过程。
建造者模式很容易进行扩展。如果有新的需求，通过实现一个新的建造者类就可以完成，基本上不用修改之前已经测试通过的代码，因此也就不会对原有功能引入风险。符合开闭原则。
缺点：
造者模式所创建的产品一般具有较多的共同点，其组成部分相似，如果产品之间的差异性很大，则不适合使用建造者模式，因此其使用范围受到一定的限制。
Builder模式的应用
在Java实际应用中，我们经常使用到"池"的概念，当资源提供者无法提供足够的资源，并且这些资源需要被很多用户反复共享时，就需要使用池。
“池”实际是一段内存，当池中有一些复杂的资源的“断肢”（比如数据库的连接池，也许有时一个连接会中断），如果循环再利用这些“断肢”，将提高内存使用效率，提高池的性能。修改Builder模式中Director类使之能诊断“断肢”断在哪个部件上，再修复这个部件。
建造者模式适用于以下的几种场景：
- 相同的方法，不同的执行顺序，产生不用的结果时
- 多个部件或者零件，都可以装配到一个对象中，但是产生的结果又不相同
- 产品非常复杂，或者产品类中的调用顺序不用产生不同的作用
- 当时初始化一个对象特别复杂，参数多，而且很多参数都具有默认值时
创建者模式对比
工厂方法模式VS建造者模式
工厂方法模式注重的是整体对象的创建方式；而建造者模式注重的是部件构建的过程，意在通过一步一步地精确构造创建出一个复杂的对象。
我们举个简单例子来说明两者的差异，如要制造一个超人，如果使用工厂方法模式，直接产生出来的就是一个力大无穷、能够飞翔、内裤外穿的超人；而如果使用建造者模式，则需要组装手、头、脚、躯干等部分，然后再把内裤外穿，于是一个超人就诞生了。
抽象工厂模式VS建造者模式
抽象工厂模式实现对产品家族的创建，一个产品家族是这样的一系列产品：具有不同分类维度的产品组合，采用抽象工厂模式则是不需要关心构建过程，只关心什么产品由什么工厂生产即可。
建造者模式则是要求按照指定的蓝图建造产品，它的主要目的是通过组装零配件而产生一个新产品。如果将抽象工厂模式看成汽车配件生产工厂，生产一个产品族的产品，那么建造者模式就是一个汽车组装工厂，通过对部件的组装可以返回一辆完整的汽车。
