1700476750
汽车型号：G系列SUV
1700476751
1700476752
对外界调用者来说，只要更换一个具备相同结构的对象，即可发生非常大的改变，如我们原本使用BenzFactory生产汽车，但是过了一段时间后，我们的系统需要生产宝马汽车，这对系统来说不需要很大的改动，只要把工厂类使用BMWFactory代替即可，立刻可以生产出宝马车，注意这里生产的是一辆完整的车，对于一个产品，只要给出产品代码（车类型）即可生产，抽象工厂模式把一辆车认为是一个完整的、不可拆分的对象。它注重完整性，一个产品一旦找到一个工厂生产，那就是固定的型号，不会出现一个宝马工厂生产奔驰车的情况。那现在的问题是我们就想要一辆混合的车型，如奔驰的引擎，宝马的车轮，那该怎么处理呢？使用我们的建造者模式！
1700476753
1700476754
1700476755
1700476756
1700476757
设计模式之禅 30.2.2 按建造者模式生产车辆
1700476758
1700476759
按照建造者模式设计一个生产车辆需要把车辆进行拆分，拆分成引擎和车轮两部分，然后由建造者进行建造，想要什么车，你只要有设计图纸就成，马上可以制造一辆车出来。它注重的是对零件的装配、组合、封装，它从一个细微构件装配角度看待一个对象。我们来看生产车辆的类图，如代码清单30-4所示。
1700476760
1700476761
1700476762
1700476763
1700476764
图30-4 建造者模式建造车辆
1700476765
1700476766
注意看我们类图中的蓝图类Blueprint，它负责对产品建造过程定义。既然要生产产品，那必然要对产品进行一个描述，在类图中我们定义了一个接口来描述汽车，如代码清单30-23所示。
1700476767
1700476768
代码清单30-23 车辆产品描述
1700476769
1700476770
public interface ICar{
1700476771
1700476772
//汽车车轮
1700476773
1700476774
public String getWheel（）；
1700476775
1700476776
//汽车引擎
1700476777
1700476778
public String getEngine（）；
1700476779
1700476780
}
1700476781
1700476782
我们定义一辆车必须有车轮和引擎，具体的产品如代码清单30-24所示。
1700476783
1700476784
代码清单30-24 具体车辆
1700476785
1700476786
public class Car implements ICar{
1700476787
1700476788
//汽车引擎
1700476789
1700476790
private String engine；
1700476791
1700476792
//汽车车轮
1700476793
1700476794
private String wheel；
1700476795
1700476796
//一次性传递汽车需要的信息
1700476797
1700476798
public Car（String_engine,String_wheel）{
1700476799