假设创建游戏中的一个房屋House设施，该房屋的构建由几部分组成，且各个部分富于变化。如果使用最直观的设计方法，每一个房屋部分的变化，都将导致房屋构建的重新修正。 动机（Motivation): 在软件系统中，有时候面临一个"复杂对象"的创建工作，其通常由各个部分的子对象用一定算法构成;由于需求的变化，这个复杂对象的各个部分经常面临着剧烈的变化，但是将它们组合到一起的算法却相对稳定。 如何应对种变化呢？如何提供一种"封装机制"来隔离出"复杂对象的各个部分"的变化，从而保持系统中的"稳定构建算法"不随需求的改变而改变。 将一个复杂对象的构建与其表示相分离，使得同样的构建过程可以创建不同的表示。
创建者模式关注的是零件类型和装配工艺（顺序），这是它与工厂方法模式最大不同的地方。
建造者模式最主要的功能是基本方法的调用顺序安排，也就是这些基本方法已经实现了，通俗地说就是零件的装配，顺序不同产生的对象也不同；而工厂方法则重点是创建，创建零件是它的主要责任，组装顺序则不是它关系的。
建造者模式的结构和使用建造模式的结构
抽象建造者角色（Builder）：给出一个抽象的接口，用来规范产品对象的各个组成成分的建造。
具体建造者角色（Concrete Builder ）：
1.实现抽象建造者所申明的接口，给出一步一步地完成创建产品实例的操作。
2.在建造过程完成后，提供产品的实例。
导演者角色（Director）：用来调用具体建造者以创建产品对象。
产品角色（Product）：要建造的对象。
Builder模式 主要用于“分步骤构建一个复杂的对象”。在这其中“分步骤”是一个稳定的乘法，而复杂对象的各个部分则经常变化。Builder模式主要在于应对“复杂对象各个部分”的频繁需求变动。其缺点在于难以应对“分步骤构建算法”的需求变动。Abstract Factory模式解决“系列对象”的需求变化，Builder模式解决“对象部分”的需求变化。Builder械通常和Composite模式组合使用。
建造者模式的UML图
UML结构图
建造者模式JAVA代码实现//最终要建造的对象
public class House {
int roomNumber;
int doorNumber;
public House() {
roomNumber = 0;
doorNumber = 0;
}
public int getRoomNumber() {
return roomNumber;
}
public int getDoorNumber() {
return doorNumber;
}
}
public abstract class HouseBuilder {
public abstract void buildRoom(int roomNo);
public abstract void buildDoor(int room1, int room2);
public abstract House getHouse();
}
//建造房子的功能类
public class ConcreteHouseBuilderA extends HouseBuilder {
private House house;
public ConcreteHouseBuilderA() {
house = new House();
}
public void buildRoom(int roomNo) {
house.roomNumber ;
}
public void buildDoor(int room1, int room2) {
house.doorNumber ;
}
public House getHouse() {
return house;
}
}
public abstract class HouseBuilder {
public abstract void buildRoom(int roomNo);
public abstract void buildDoor(int room1, int room2);
public abstract House getHouse();
}
//建造房子的功能类
public class ConcreteHouseBuilderA extends HouseBuilder {
private House house;
public ConcreteHouseBuilderA() {
house = new House();
}
public void buildRoom(int roomNo) {
house.roomNumber ;
}
public void buildDoor(int room1, int room2) {
house.doorNumber ;
}
public House getHouse() {
return house;
}
}
建造者模式的优点和使用场景- 优点
封装性 使用建造者模式可以是客户端不必知道产品内部组成的细节。
建造者独立，容易扩展
便于控制细节风险 由于具体的建造者是独立的，因此可以对建造过程逐步细化，而不对其他的模块产生任何影响。
- 使用场景
相同的方法，不同的执行顺序，产生不同的事件结果时，可以采用建造者模式。
多个部件或零件，都可以装配到一个对象中，但是产生的运行结果又不相同时，则可以使用该模式。
产品类非常复杂，或者产品类中的调用顺序不同产生了不同的效能，这个时候使用建造者模式非常合适。
在对象的创建过程中会使用到系统中的一些其他对象，这些对象在产品对象的创建过程中不易得到时，也可以使用建造者模式封装该对象的创建过程。该种场景只能是一个补偿方法，因为一个对象不容易获得，而在设计阶段竟然没有发觉，而要通过创建者模式柔化创建过程，这本身已经违反设计的最初目标。
