前面学习了简单工厂模式，工厂方法模式以及抽象工厂模式，这些都是创建类的对象所使用的一些常用的方法和套路， 那么如果我们创建一个很复杂的对象可上面的三种方法都不太适合，那么“专业的事交给专业人去做”，23设计模式总有一个模式是适合这种复杂对象的创建。比如现在的智能手机组成, 它包括一个屏幕，摄像头，耳机接口，USB接口，CPU， RAM，主板等等, 但是每一个型号的手机的屏幕又不一样，有的是刘海的，有的是全屏的，有的是全面屏的，CUP 也不一样，有骁龙820 的，有 660的还有麒麟920 的等等，手机的组成图如下：
那么要创建一个这样的复杂对象, 该怎么创建呢？ 那么该建造者模式闪亮登场了。
建造者模式(Builder Pattern)：将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。建造者模式是一种对象创建型模式。
它为创建一个产品Product对象的各个部件指定抽象接口，在该接口中一般声明两类方法，一类方法是buildPartX()，它们用于创建复杂对象的各个部件；另一类方法是GetResult()，它们用于返回复杂对象。AbstractBuilder既可以是抽象类，也可以是接口。
它实现了AbstractBuilder接口，实现各个部件的具体构造和装配方法，定义并明确它所创建的复杂对象，也可以提供一个方法返回创建好的复杂产品对象。
它是被构建的复杂对象，包含多个组成部件，具体建造者创建该产品的内部表示并定义它的装配过程。
负责安排复杂对象的建造次序，导演与抽象建造者之间存在关联关系，可以在其Construct()建造方法中调用建造者对象的部件构造与装配方法，完成复杂对象的建造。客户端一般只需要与指挥者进行交互，在客户端确定具体建造者的类型，并实例化具体建造者对象（也可以通过配置文件和反射机制），然后通过指挥者类的构造函数将该对象传入指挥者类中。
客户端调用：
输出结果：
我们用本文开头提出的手组成的例子来挑选几个核心部件来构造几个型号的手机，使用建造者模式。
1、X1型手机：CUP 骁龙 835， RAM 6GB ，屏幕 刘海全屏, 硬盘 64GB。
2、X2 型手机： CUP 麒麟 930, RAM 8G, 屏幕 全面屏, 硬盘 128GB。
3、X3型手机： CPU 骁龙 960 RAM 10G，屏幕 超清全面屏 256GB。
UML 图如下：
代码：
调用代码如下：
如果想生产X2型号的手机，只需要将具体建造者代码修改一下就可以了，即将下面的一行代码：
改成：
也可以将具体建造者类配置在配置文件中，通过反射来创建建造者对象进而创建出新的型号的手机。
在配置文件中加入如下配置：
客户端调用代码如下：
在建造者模式中，客户端不必知道产品内部组成的细节，将产品本身与产品的创建过程解耦，使得相同的创建过程可以创建不同的产品对象。
每一个具体建造者都相对独立，而与其他的具体建造者无关，因此可以很方便地替换具体建造者或增加新的具体建造者，用户使用不同的具体建造者即可得到不同的产品对象。由于指挥者类针对抽象建造者编程，增加新的具体建造者无须修改原有类库的代码，系统扩展方便，符合“开闭原则（OCP）“
可以更加精细地控制产品的创建过程。将复杂产品的创建步骤分解在不同的方法中，使得创建过程更加清晰，也更方便使用程序来控制创建过程
建造者模式所创建的产品一般具有较多的共同点，其组成部分相似，如果产品之间的差异性很大，例如很多组成部分都不相同，不适合使用建造者模式，因此其使用范围受到一定的限制。
如果产品的内部变化复杂，可能会导致需要定义很多具体建造者类来实现这种变化，导致系统变得很庞大，增加系统的理解难度和运行成本。
需要生成的产品对象有复杂的内部结构，这些产品对象通常包含多个成员属性。
需要生成的产品对象的属性相互依赖，需要指定其生成顺序。
对象的创建过程独立于创建该对象的类。在建造者模式中通过引入了指挥者类，将创建过程封装在指挥者类中，而不在建造者类和客户类中。
隔离复杂对象的创建和使用，并使得相同的创建过程可以创建不同的产品。
Director在建造者模式中扮演着重要的角色，Director类看似简单但是作用却非常大，它决定复杂对象各个部分的创建顺序并且将构建对象的过程和具体建造者隔离，比如创建一个房子，首先肯定要做的事情是打地基，然后是磊墙，然后是封顶，最后是装修，这个过程是有顺序的且必须是这个顺序，其它过程不无法完成房子的建造。
Director'就好像是拍电影导演一样，导演要拍一部电影，需要拍摄若干影像片段，最后由剪辑师做剪接拼接，导演最后会进行最终的剪辑排版合成一个长片-- 电影。那么电影就充当了建造者模式中的复杂产品，拍摄的影像片段就是产片的各个部分，剪辑就是建造者模式的具体具体建造者，剧本是建造者模式的抽象建造者，导演就是Director。那么在在这个过程中，编剧是不可以兼任导演？ 剪辑师是不是也可以兼任导演呢？答案是肯定的。
那上面手机建造的实例，删除掉Diretor， 将创建复杂对象的逻辑放到抽象建造者中，并且使子类方法不能重写父类中的建造产品的方法，引用之前的配置代码演变成如下：
调用代码：
这种在抽象建造者中使用了一个静态方法来创建产品的做法的好处是产品创建出来的一致性很好，创建产品流程被统一封装，一般不会有差异，这种方式抽象类控制了产品建造的顺序，并且所有的产品的创建顺序都不能改变了（如造房子的流程），对于要求创建顺序一致，并且产品部件的创建都路程一致的产品来说这是一个优点。
但是如果想创建出来的产品有差异，每一个产品的顺序都不一样那该怎么办呢？比如现在这种方法创建出来的顺序是： CPU=》Screen=》RAM=》Disk， 那么我要想X3型号的手机创建顺序变成：CPU=》RAM=》Disk=》Screen。 这种方法就显得不灵活了，没有办法做到个性化了。处理典型的将建造过程的控制权交给Director外，还可以不用Director来完成吗？
这里我们依然删掉Director， 将抽象方法中的创建方法变成子类可以重写的虚方法就可以了，然后在具体建造者中重写抽象建造者的创建方法就可以了。
现在我们创建X1，X2，X3型号的手机的顺序分别是这样的：
X1： CPU=》Screen=》RAM=》Disk
X2：CPU=》RAM=》Disk=》Screen
X3：CPU=》Disk=》RAM=》Screen
代码如下：
假如要造一个X4型号的手机，这个手机支持NFC，我们知道X1，X2，X3中都不支持NFC，那怎么办呢？，我们可以给抽象建造者类加一个方法，叫 HasNFC（）并且返回bool值，并将其设置成默认值为false。 修改抽象建造者的GetMobile（） 方法，只有当HasNFC（）返回 true是才创建NFC模块，并且在X4Builder的具体建造者类中重写HasNFC（）方法使其返回true就可以了。
App.Config 配置：
客户端代码：
修改配置文件，使其造一台X4 如下，调用代码不变：
好了建造者模式就探讨到这里。