大卫的Design Patterns学习笔记03：Builder
大卫的Design Patterns学习笔记03：Builder
一、概述
Builder（生成器）模式将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。
跟Factory Pattern一样，Builder Pattern的目的也在于构建对象，并且与Abstract Factory相似，往往也包含多个Factory Method，但与Abstract Factory不同的是，Builder Pattern通过组装多个Part，最终构成一个独立的产品提供给上层应用，而Abstract Factory则往往构建多个独立的产品。
二、结构
Builder模式的类图如下所示：
图1：Builder模式的类图
上图中包括以下几个组成部分：
Builder（抽象生成器）角色：这个角色用来规范产品对象的各个组成成分的建造。一般而言，此角色独立于应用程序的商业逻辑。
Concrete Builder（具体生成器）角色：担任这个角色的是于应用程序紧密相关的类，它们在指导者的调用下创建产品实例。这个角色在实现抽象建造者角色提供的方法的前提下，达到完成产品组装，提供成品的功能。
Director（指导者）角色：调用具体建造者角色以创建产品对象。指导者并没有产品类的具体知识，真正拥有产品类的具体知识的是具体建造者对象。
Product（产品）角色：待创建的复杂对象。它要包含那些定义组件的类，包括将这些组件装配成产品的接口。
三、应用
在以下情况下应该考虑使用Builder模式：
1、当创建复杂对象的算法应该独立于该对象的组成部分以及它们的装配方式时。
2、当构造过程必须允许被构造的对象有不同的表示时。
个人认为Builder模式可以被视为复杂化了的Simple Factory（创建了多个子产品，但最终组合到一起），但Builder模式的关键在于在创建一个复杂对象时，其组合过程往往涉及复杂的处理，同时，这种职责的分离使得修改复杂对象的组合逻辑变得独立而简单。
四、优缺点
职责分离，使程序的结构更加清晰，当需要提供新的产品时，只需要从Builder基类派生新的ConcreteBuilder类，在其中实现新产品的创建工作，如果我们需要新的产品，或者调整新产品的创建过程，只需要对调用Builder类接口进行产品构建处的代码作简要修改即可，因为产品各部分的构建过程已经封装在ConcreteBuilder类中了。
在Factory Method模式中，产品内部的表象是由产品自身来决定的；而在Builder模式中则是“外部化”为由Builder来负责。这样定义一个新的具体Builder角色就可以改变产品的内部表象，符合“开闭原则”。
Buider模式使得客户不需要知道太多产品内部的细节。它将复杂对象的创建和表示方式封装在一个具体的Builder角色中，并由Director来协调Builder角色来得到具体的产品实例。
Builder模式可以对复杂产品的创建进行更加精细的控制，产品的组成是由Director角色调用具体Builder角色来逐步完成的，所以比起其它创建型模式能更好的反映产品的构造过程。
五、扩展
在理解Builder模式时，有几点需要注意：1、Builder模式与其它创建型模式一样，将产品的创建（Builder类系）与产品的使用分离（Client）开来，通过实现ConcreteBuilder来构建不同的产品；2、除了Builder类系，Builder模式中还存在一个重要的角色：Director。Director这个角色在Builder模式中常常被忽略，但个人认为，Director对于我们理解和运用Builder模式有着重要作用，Builder及其子类负责产品各组成部分的创建，而Director负责产品的组装，二者缺一不可（有些情况下，我们可以考虑将Director类的所担负的组装的职责移植到客户代码或Builder类中实现，虽然Director的角色没有了，其功能仍然存在，但这样就失去了Director可扩展的优点）；3、由于Builder模式将对象的组装从对象创建类系中分离出来，因此，可以通过向Director类传递不同的ConcreteBuilder，达到 “同样的构建过程可以创建不同的表示”，即同样的创建过程可以创建不同的产品的效果，这正是Builder模式的意义所在。
此外，除了在Builder类系一方进行扩展，我们也可以在Director类系一方对Builder模式进行扩展，扩展成有多个ConcreteDirector的情况，每个ConcreteDirector负责完成一种组装产品的方式，如ConcreteDirector1使用builder.BuildPartA + builder.BuildPartB来组装产品，而ConcreteDirector2使用builder.BuildPartA + builder.BuildPartC来组装产品，从而实现更加复杂的“产品生产线”。
六、举例
Builder模式的结构相对比较简单，基本无需更多的说明，下面用一段“玩具”代码来演示一下该模式的实现方法，具体应用中getProduct可以作为Director类的成员方法，也可以作为Builder类的成员方法，实际应用中可根据需要而定：
#include <iostream>
#include <algorithm>
#include <string>
#include <vector>
using namespace std;
// to simplify problem, just use string as ProductPart type.
typedef string ProductPart;
struct PCBuilder
{
virtual void prepareMonitor() = 0;
virtual void prepareCPU() = 0;
virtual void prepareHarddisk() = 0;
// ...
vector<ProductPart>& getProduct() { return product; }
vector<ProductPart> product;
};
struct CheapPCBuilder : public PCBuilder
{
void prepareMonitor()
{
product.push_back("Monitor: CRT");
}
void prepareCPU()
{
product.push_back("CPU: Celeron");
}
void prepareHarddisk()
{
product.push_back("Harddisk: 40G");
}
};
struct ExpensivePCBuilder : public PCBuilder
{
void prepareMonitor()
{
product.push_back("Monitor: LCD");
}
void prepareCPU()
{
product.push_back("CPU: Pentium");
}
void prepareHarddisk()
{
product.push_back("Harddisk: 200G");
}
};
struct Director
{
void construct(PCBuilder* builder)
{
builder->prepareMonitor();
builder->prepareCPU();
builder->prepareHarddisk();
// ...
}
};
int main()
{
Director d;
PCBuilder* pb = new ExpensivePCBuilder();
d.construct(pb);
vector<ProductPart> product = pb->getProduct();
cout << "We got a PC made up of:" << endl;
copy(product.begin(), product.end(), ostream_iterator<string>(cout, "/n"));
return 0;
}