复杂对象的创建--建造者模式（Builder）

1初识建造者模式

建造者模式实际上是常用的设计模式。顾名思义，builder的意思是建造者或者建筑工人，谈到建造自然会想到楼房。楼房是千差万别的，楼房的外形、层数、内部房间的数量、房间的装饰等等都不一样，但是对于建造者来说，抽象出来的建筑流程是确定的，往往建筑一座楼房包括下面的步骤：（1）打桩，建立基础（2）建立框架等。建造者模式的本质和建造楼房是一致的：即流程不变，但每个流程实现的具体细节则是经常变化的。建造者模式的好处就是保证了流程不会变化，流程即不会增加、也不会遗漏或者产生流程次序错误，这是非常重要的。我们熟知的楼歪歪事件，官方的解释就是由于先建立楼房后，再建设停车场造成的，这是典型的建造次序错乱。（看来这些人儿不知道建造者模式啊！！！）

我生活的地方有一个菜叫“锅包肉”。基本每个餐馆都有，但是每个餐馆的味道都不一样，原因是什么呢？因为这道菜的作法没有形成标准呗！每个人的作法都不一样，所以味道就不一样了。这实际上通过“建造者模式”让每个馆子的“锅包肉”都一样。同样的KFC做出来的东西，不论是全国哪家店做出来就都一个味，因为KFC内部有很严格的规定，做巨无霸有做巨无霸的流程，必须严格遵守，这样做出来的东西当然一致了。KFC就是采用了建造者模式！！

说了这么多，到底什么是建造者模式呢？这么神奇。看看GoF怎么说。

建造者模式：是将一个复杂的对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。

建造者模式通常包括下面几个角色：

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

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

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

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

按照惯例，还是给出建造者模式的结构图

---

---

2 一个建造者模式例子实现

不妨就实现《大话设计模式》上的建造小人的例子吧！！在游戏开发中建造小人是经常的事了，要求是：小人必须包括，头，身体，手和脚。现在系统要包括的分为胖人和瘦人。写出建造者模式的代码如下：

#include <iostream>
#include <vector>
#include <string>

using namespace std;

//Product类
//这个类不是那么重要，它只是一个产品类，一个产品由很多部件组成，
//Builder接口是精华，它规定了生产这样一个产品的流程
//Builder接口的实现类则是细节，是多态，从一个流程下创建同类但不同型号的产品

//多态可以简单理解为用基类调用不同的具体实现，所以我们往往会用一个方法，或是一个类，来封装在不同条件下调用不同实现的代码，本文提到的Director就是起到这个普遍作用，没有什么特殊的，不要被这一个个的定义弄糊涂了。
class Product
{
    vector<string> parts;
public:
    void Add(const string part)
    {
        parts.push_back(part);
    }
    void Show()const
    {
        for(int i = 0 ; i < parts.size() ; i++)
        {
            cout<<parts[i]<<endl;
        }
    }
};

//抽象builder类
class Builder
{
public:
    virtual void BuildHead() = 0;
    virtual void BuildBody() = 0;
    virtual void BuildHand() = 0;
    virtual void BuildFeet() = 0;
    virtual Product GetResult() = 0; 
};

//具体胖人创建类
class FatPersonBuilder :public Builder
{
private:
    Product product;
public:
    virtual void BuildHead()
    {
        product.Add("胖人头");//创建瘦人的头
    }
    virtual void BuildBody()
    {
        product.Add("胖人身体");//创建瘦人的身体
    }
    virtual void BuildHand()
    {
        product.Add("胖人手");//创建瘦人的手
    }
    virtual void BuildFeet()
    {
        product.Add("胖人脚");//创建瘦人的脚
    }
    virtual Product GetResult()
    {
        return product;
    }
};

//具体瘦人人创建类
class ThinPersonBuilder :public Builder
{
private:
    Product product;
public:
    virtual void BuildHead()
    {
        product.Add("瘦人人头");//创建瘦人的头
    }
    virtual void BuildBody()
    {
        product.Add("瘦人身体");//创建瘦人的身体
    }
    virtual void BuildHand()
    {
        product.Add("瘦人手");//创建瘦人的手
    }
    virtual void BuildFeet()
    {
        product.Add("瘦人脚");//创建瘦人的脚
    }
    virtual Product GetResult()
    {
        return product;
    }
};

//Director类
class Director
{
public:
    void Construct(Builder &builder)
    {
        builder.BuildHead();
        builder.BuildBody();
        builder.BuildHand();
        builder.BuildFeet();
    }
};

int main()
{
    Director *director = new Director();
    Builder *b1 = new FatPersonBuilder();
    Builder *b2 = new ThinPersonBuilder();

    director->Construct(*b1);
    Product p1 = b1->GetResult();
    p1.Show(); 
    return 0;
}

看过上面代码发现使用建造者模式有什么好处了吗？上面的例子，通过建造者模式，使得建造过程通过Director类的Construct函数固定了，即建造过程不会变，也就是满足上面要求中红色字体的“必须包括”。但是具体的头，身体，手脚这些身体的各个部分会变化，基类Builder中将各种Build函数定义为抽象方法，必须在子类中实现。这样不仅仅使得建造小人的过程不变，而且很利于系统的扩展，一旦出现其他种类的人根本不需要改动之前的FatPersonBuider，ThinPersonBuilder，Director，Product等类，只需要新添加新的类。符合OCP原则。

到这里不知道大家有没有这样的疑问，建造者模式和工厂方法模式非常相似啊，确实是非常的相似，建造者模式注重零部件的组装过程，而工厂方法模式更注重零部件的创建过程。

工厂方法模式：
【一个工厂可以创建多种不同的产品，所以定义产品的接口，利用产品的多态。】把一个类的实例化延迟到它的子类中，核心的工厂类不负责所有产品的创建，而是将具体创建的工作交给子类去做。让子类决定实例化哪一个类。即抽象工厂角色。

抽象工厂模式：
【在工厂方法模式的基础上，解决工厂过多的问题，所以也提供工厂的接口】向客户端提供一个接口，使得客户端在不必指定产品的具体类型的情况下，创建多个产品族中的产品对象。既提供一个创建一系列相关或相互以来对象的接口，而无需指定它们的具体的类，这就是抽象工厂模式的用意。是工厂方法模式的进一步推广。

建造者模式：
【如果上面两种模式用生成零件来比喻的话，那么Builder关注的更多的是组装。所以很多情况是抽象工厂+建造者模式】将一个产品的内部表象和产品的生成过程分开来，从而可以使一个建造过程生成具有不同的内部表象的产品对象。