引言
不用怀疑，你一定遇到和使用过它，它在Android源码和各种开源组件中是如此常见。这是一种你可以不知道怎么运用，但是知道了会欲罢不能的设计模式。
定义
Builder模式（建造者模式，有人称作生成器模式），将一个复杂对象的构建与他的表示分离，使得同样的构建过程可以创建不同的表示。
很抽象？请看如下UML类图，进行直观的描述。
UML类图
这是在许多书籍、网络资料中非常容易找到的标准Builder设计模式类图。
角色
在上图中可以清楚地看到Builder模式里的四种角色。
- Builder：抽象的建造者。
- ConcreteBuilder：具体的建造者，继承自Builder，通常不止一个
- Product：被构造的复杂对象
- Director：指挥者，指挥建造者去建造一个产品
上图中的ConcreteBuilder和Product是一一对应关系，实际上，ConcreteBuilder和Product并不只有一对，因此Builder模式的实际UML类图呈现如下形式。
细心的你早已洞察一切，拿掉Director角色后，上下两部分是一个对称结构。而上文也提到，Builder常常以内部类的形式出现。因此，抽象的Builder定义在抽象的Product内部，具体的ConcreteBuilderA定义在具体的ProductA内部，具体的ConcreteBuilderB定义在具体的ProductB内部……
Builder模式的简单实现
以上描述实在太过抽象，具体的示例代码早已呼之欲出。
Computer类对应于Product角色，它的内部定义了一个静态的Builder类。配置和初始化都交给Builder去做了，因此Computer本身并不提供对任何属性的setter，也不提供以任何属性为参数的构造函数。
public class Computer {
protected String mBoard;
protected String mDisplay;
protected String mOS;
protected Computer(Builder builder) {
this.mBoard = builder.board;
this.mDisplay = builder.display;
this.mOS = builder.os;
}
public static abstract class Builder {
protected String board;
protected String display;
protected String os;
public abstract Computer.Builder buildBoard(String board);
public abstract Computer.Builder buildDisplay(String display);
public abstract Computer.Builder buildOS();
public abstract Computer build();
}
@Override
public String toString() {
return "Computer [mBoard=" + mBoard + ", mDisplay=" + mDisplay + ", mOS=" + mOS + "]";
}
//Computer其他重要操作
}
MacBook是Computer的一个子类，对应于ProductA角色。它内部也定义了一个Builder类，对应于ConcreteBuilderA角色。因为是内部类，所以也叫Builder，不存在重名的问题。注意它的最后一个方法build()，返回一个Macbook对象，这是非常关键的一步。
public class Macbook extends Computer {
public Macbook(Builder builder) {
super(builder);
}
public static class Builder extends Computer.Builder {
@Override
public Computer.Builder buildBoard(String board) {
this.board = board;
return this;
}
@Override
public Computer.Builder buildDisplay(String display) {
this.display = display;
return this;
}
@Override
public Computer.Builder buildOS() {
this.os = "Mac OS X 10.10";
return this;
}
@Override
public Computer build() {
return new Macbook(this);
}
}
}
Computer的其他子类，如SurfacePro.java代码和Macbook类似，限于篇幅，不在此贴出。再看Director和客户端测试代码。
public class Director {
private Computer.Builder mBuilder;
public Director(Computer.Builder builder) {
this.mBuilder = builder;
}
public void buildPC(String board, String display) {
mBuilder.buildBoard(board);
mBuilder.buildDisplay(display);
mBuilder.buildOS();
}
}
Computer.Builder builder = new Macbook.Builder();
Director director = new Director(builder);
director.buildPC("Inter Board", "Apple Display");
Computer.Builder builder2 = new SurfacePro.Builder();
director = new Director(builder2);
director.buildPC("AMD Board", "LG Display");
System.out.println(builder.build().toString());
System.out.println(builder2.build().toString());
毫无悬念地，我们得到了想要的输出。
Computer [mBoard=Inter Board, mDisplay=Apple Display, mOS=Mac OS X 10.10]
Computer [mBoard=AMD Board, mDisplay=LG Display, mOS=Windows 10]
Builder模式的变形
细心的你又发现了，Computer.Builder中的三个抽象方法都都是有返回值的，在Macbook.Builder中可以看到这三个方法的具体实现中，都是先操作完Builder本身（对builder的属性进行赋值）然后再返回Builder本身。但是我们在调用这三个方法的时候（Director类的buildPC方法中）并没有使用到这一返回值。现在尝试使用它！
public void buildPC(String board, String display) {
// mBuilder.buildBoard(board);
// mBuilder.buildDisplay(display);
// mBuilder.buildOS();
mBuilder.buildBoard(board).buildDisplay(display).buildOS();
}
保存、编译、运行，输出结果一样，完全没毛病啊！将一句话封装成一个方法，还多了个类，Director是不是多余啊？试试不用Director，进行同义替换。
Computer macbook = new Macbook.Builder()
.buildBoard("Inter Board")
.buildDisplay("Apple Display")
.buildOS()
.build();
System.out.println(macbook.toString());
这就是我们常见的链式调用，非常方便易用！
小结
回到文章开头的Builder模式定义，复杂对象Macbook以三个属性board、display、和OS三个属性以及其他重要方法来表示，但是它的构建既不直接使用构造函数，也不对外提供setter，也不提供其他方法直接操作三个属性。而是金蝉脱壳，将构建和初始化过程转交给了内部的Builer去实现，此所谓“构建和表示分离”。
因为Product角色存在着明显的继承派生关系，Builder角色也与之一一对应，从上述代码示例可以看出，mBuilder.buildBoard(board).buildDisplay(display).buildOS()是统一的三部曲过程，最后的输出中Macbook和SurfacePro却是不同的配置。此所谓“同样的构建过程创建不同的表示”。
后记
限于篇幅，本文只讨论了Builder模式的两种变换：链式调用和省略指挥者角色。其实设计模式的应用非常灵活，Builder模式不但可以省略指挥者，连抽象Builder角色都可以省略。再者，由于Builder模式本身的特性，一旦Builder调用build()方法生成相应的Product对象，Product对象的任何属性值便无法再改变。哪怕Product中的99个属性相同，只有1个不同，也必须重新构建，无法复用。
敬请期待，本文的续篇
OkHttp源码中的Builder模式，
为您讲述Builder模式变换之“省略抽象Builder角色”和“Product的回炉再造”！
