建造者模式

个人感觉二代小黄车真真没有一代的好骑了，它现在所占的优势就是投入市场早，抢占了先机。

我也想造一些自行车，车头上贴上自己的二维码，然后骑着三轮车把他们投放到一个地铁口，把其他厂家的车都**，自己是不是就可以坐在马扎上数钱了，嘿嘿………

说干就干，我先高仿小黄车：焊车架，造轮子，造车筐，装车轴，装链条；好了，拉去投放市场。

摩拜貌似骑得人也不少啊，不行，我也要高仿摩拜单车：焊车架，造轮子，造车筐，装车轴，装链条；好了，拉去投放市场。

小蓝好骑，还是有必要高仿的：焊车架，造轮子，造车筐，装车轴；好了，拉去投放市场，马丹，忘了装链条了。

单车种类越来越多，我就一直在焊车架，造轮子，造车筐，装车轴，装链条，我们来看看代码如何实现：

我创建了一个imitator类，表示仿造者，这个人专门仿造其他人的东西，然后给使用者（骑手）使用。它实现了几个函数：imitateOfo()、imitateMobike()、imitateBlue()分别创建ofo、摩拜、小蓝，每个函数里都是焊车架，造轮子，造车筐，装车轴，装链条。这样的问题是，虽然我的imitator类实现了产品(自行车)与使用者的解耦和，但是imitator类要实现所有自行车产品的创建和维护，无论改了哪款车的那个零件都要修改imitator，无论增加或删除哪款车都要修改imitator，并且新增一款车的时候，我有可能因为忘记了一个组装步骤而使这款车不能用，后期的人员维护会很疲惫。

既然所有牌子的自行车都是相同步骤构建出来的，那我们就把这个构建步骤进行封装成接口，形成一个模式，每个具体实现类都用来创建一种具体表示的对象(一种牌子的自行车)，由一个导演类负责构建步骤（接口函数）的具体调用从而生成具体对象，这样新增一种不同表示的对象（新牌子自行车）只需要新增一个具体构建步骤的实现类，然后在imitator中加一个判断即可（可扩展性）。修改一种具体表示的对象（某个牌子的自行车）只需要修改这种对象对应的构建类就好了，不会影响到其他种对象的创建（低耦合性），从某种程度上实现了一个类的构建代码和表示代码的分离。这种模式就叫建造者模式。

 

建造者模式描述一种流程，它对 一个类 或一批构建过程都相同的类 的复杂 的实例化过程进行 封装，实现对象的构建与它的表示分离，使得同样的构建过程代码可以创建不同的表示供调用者使用。个人认为当需要一种既定的构建过程使一个类的最终对象有不同的表现，或者需要一种相同的既定构建过程对多个（后续可能动态增加）构建过程相同的类的构建过程进行封装（约束），这个时候就可以使用建造者模式进行封装。

 

一、个人理解

1、官网上说建造者模式的具体含义：将一个复杂的对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。个人认为凡事都可变通：一个类通过一种构建过程（类似于各种set属性函数集合）将这个类的复杂的构建过程细化，使得生成的具体对象可以有不同的表现。同时将一些易变的代码进行封装，使得这个类不会过于频繁的被修改；一些动态增加的类，如果他们的复杂的构建过程相同，我也可以使用建造者模式对他们封装，使得这些类的实例有不同的表示。

 

二、特征

1、构建过程相同，将构建过程封装成接口，每一个具体实现类负责一种 具体表示的对象 的构建，由导演类负责调用构建过程。

2、这些拥有不同表示的类或对象应该很复杂，需要知道凡事过犹不及，解耦造成的结果就是系统逻辑结构的复杂化，一个简单的new就能完成实例化过程的类根本不需要有建造者对其封装。

 

三、实现

1. builder：给出一个抽象接口，以规范产品对象的各个组成成分的建造。这个接口规定要实现复杂对象的哪些部分的创建，并不涉及具体的对象部件的创建。

2. ConcreteBuilder：实现Builder接口，针对不同的商业逻辑，具体化复杂对象的各部分的创建。 在建造过程完成后，提供产品的实例。

3. Director：调用具体建造者来创建复杂对象的各个部分，在指导者中不涉及具体产品的信息，只负责保证对象各部分完整创建或按某种顺序创建。

4. Product：要创建的复杂对象。