一、建造者模式
定义
将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。
特点
1.在某些属性没有赋值之前，复杂对象不能作为一个完整的产品使用。比如汽车包括方向盘、车门、发动机等各部件，缺少了这些部件就不能生产使用。
2.对象的一些属性必须按照顺序赋值，比如汽车应有车架才能装车轮和其他部件。
UML
从上面的UML可以看出，建造者模式涉及到以下四个角色的概念：
- 抽象建造者角色：提供一个接口，规范产品对象的建造，一般由子类实现。一般来说，产品的组成部分数与建造方法数相同，即有多少组成部分，就有多少个建造方法。
- 具体建造者角色：该角色实现了抽象建造者抽象建造者接口，主要是实现所有声明的方法以及返回建造好的产品实例。
- 导演者角色：负责调用具体建造者按照顺序建造产品。导演者只负责调度，真正执行的是具体建造者角色。
- 产品角色：该角色是建造的复杂对象，提供基本方法。
二、实战
上代码
现在要做两辆万众瞩目的豪车，一辆兰博基尼，fine。另一辆法拉利，ok。一起来看看怎么造这两台车...
产品角色代码如下：
public class Production {
private String part1;
private String part2;
public String getPart1() {
return part1;
}
public void setPart1(String part1) {
this.part1 = part1;
}
public String getPart2() {
return part2;
}
public void setPart2(String part2) {
this.part2 = part2;
}
}
抽象建造者角色代码如下：
public interface IBuilder {
// 产品有多少个组件，就有多少个建造方法
public void buildPart1();
public void buildPart2();
// 返回产品类
public Production build();
}
首先来看兰博基尼怎么做，代码如下：
public class BuilderA implements IBuilder {
private Production production = new Production();
@Override
public void buildPart1() {
System.out.println("构造兰博基尼的第一部分。");
production.setPart1("This is part1 of Lamborghini");
}
@Override
public void buildPart2() {
System.out.println("构造兰博基尼的第二部分。");
production.setPart2("This is part2 of Lamborghini");
}
@Override
public Production build() {
System.out.println("咔擦！兰博基尼已造好！");
return production;
}
}
导演者角色调度构建，代码如下：
public class Director {
private IBuilder builder;
public Director(IBuilder builder){
this.builder = builder;
}
/**
* 构造顺序
*/
public Production construct(){
builder.buildPart1();
builder.buildPart2();
return builder.build();
}
}
下面看看客户端如何使用建造者模式把兰博基尼造出来，代码如下：
public class Client {
public static void main(String[] args){
// 兰博基尼
IBuilder builderA = new BuilderA();
Director directorA = new Director(builderA);
directorA.construct();
}
}
运行客户端代码，结果如下：
构造兰博基尼的第一部分。构造兰博基尼的第二部分。
咔擦！兰博基尼已造好！
接下来要造法拉利了，步骤一样，先实现抽象建造者接口。
法拉利具体建造者代码如下：
public class BuilderB implements IBuilder {
private Production production = new Production();
@Override
public void buildPart1() {
System.out.println("构造法拉利的第一部分。");
production.setPart1("This is part1 of Ferrari");
}
@Override
public void buildPart2() {
System.out.println("构造法拉利的第二部分。");
production.setPart2("This is part2 of Ferrari");
}
@Override
public Production build() {
return production;
}
}
客户端建造法拉利代码如下：
public class Client {
public static void main(String[] args) {
// 法拉利
IBuilder builderB = new BuilderB();
Director directorB = new Director(builderB);
directorB.construct();
}
}
客户端运行结果如下：
构造法拉利的第一部分。构造法拉利的第二部分。
咻咻！法拉利已造好！
三、建造者模式的优缺点
优点
1）降低代码耦合度。在建造者模式中，客户端不需要知道产品内部是如何实现的，我们只需得到产品的对象。并且使用导演者和建造者分离组装过程和组件具体构造过程，具有灵活的扩展性。
2）优秀的扩展性。具体建造者相互独立，方便扩展，符合开闭原则。
缺点
1）一定的使用范围限制。建造者模式的产品的组件基本相同，如果产品的差异性较大，建造者模式就不适用了。
四、比较
跟工厂方法模式对比：建造者模式和工厂模式同样是创建一个产品，工厂模式就是一个方法，而建造者模式有多个方法，并且建造者模式是有顺序的执行方法。就是说建造者模式强调的是顺序，而工厂模式没有顺序一说。
五、总结
建造者模式就是这样。那到最后，我们必须要思考一下为什么这么做？学而不思则罔，我们纵观全部代码，其实我们就会发现，在最后的Client 类中，我们其实根本就不会知道具体是怎么造车的，因为这个过程让director给代劳了。然后，我们的BuilderA类中才是真正的车方法。director其实只是执行了这个过程。这样子，达到了分离模块的功能。造车的过程，启动造车的过程，和最后选择哪种车来造。都分的清清楚楚。就有了一些模块化的感觉，这样维护和扩展都是很方便的。所以设计模式的精髓还是那几个原则。感觉原则才是法则，而这么多模式就是具体的招式。