Builder模式的缘起
- 假设创建游戏中的一个房屋House设施，该房屋的构建由几个部分组成，且各个部分要富于变化。
- 如果使用最直观的设计方法，每一个房屋部分的变化，都将导致房屋构建的重新修正…
动机（Motivation）
在软件系统中，有时候面临着“一个复杂对象”的创建工作，其通常由各个部分的子对象用一定的算法构成；由于需求的变化，这个复杂对象的各个部分经常面临着剧烈的变化，但是将它们组合在一起的算法却相对稳定。
如何应对这种变化？如何提供一种“封装机制”来隔离出“复杂对象的各个部分”的变化，从而保持系统中的“稳定构建算法”不随着需求改变而改变？
意图（Intent）
将一个复杂对象的构建与其表示相分离，使得同样的构建过程可以创建不同的表示。
结构（Structure）
Director使用者/客户程序 Builder生成器
配置文件在一些情况下可以防止代码的修改，程序通过反射得到类型，需要修改时只需要修改配置文件里的内容，而不修改代码，不需要重新编译。
生成器模式角色
-
Product产品类
-
Builder抽象生成器
-
ConcreteBuilder具体生成器
-
Director导演类
Builder模式的几个要点
- Builder模式主要用于“分步骤构建一个复杂的对象”。在这其中“分步骤”是一个稳定的算法，而复杂对象的各个部分则经常变化。
- 变化点在哪里，封装哪里——Builder模式主要在于应对“复杂对象各个部分”的频繁需求变动。其缺点在于难以应对“分步骤构建算法”的需求变动。
- Abstract Factory模式解决“系列对象”的需求变化，Builder模式解决“对象部分”的需求变化。Builder模式通常和Composite模式组合使用。
使用场景
-
相同的方法，不同的执行顺序，产生不同的事件结果时，可以采用生成器模式。
-
多个部件或零件，都可以装配到一个对象中，但是产生的运行结果又不相同时，则可以使用该模式。
-
产品类非常复杂，或者产品类中的调用顺序不同产生了不同的效能，这个时候使用生成器模式非常适合。
示例代码
产品类：
public class Product{
public void doSomething(){}
}
抽象生成器：
public abstract class Builder{
//设置产品的不同部分，以获得不同的产品
public abstract void setPart();
//建造产品
public abstract Product buildProduct();
}
具体生成器：
public class ConcreteBuilder extends Builder{
private Product product = new Product();
//设置产品零件
public void setPart(){
//产品类内的逻辑处理
}
//组建一个产品
public Product buildProduct(){
return product;
}
}
导演类：
public class Director{
private Builder builder = new ConcreteBuilder();
//构建不同的产品
public Product getProduct(){
builder.setPart();
/*
* 设置不同的零件、产生不同的产品
*/
return builder.buildProduct();
}
}