每一个人的需求都不同
好比咱们如今已经用程序实现了一个汽车启动的全过程：启动，发动引擎，鸣笛，停车。具体实现可参考个人上篇文章“设计模式篇——模板方法模式详解”。上面的顺序是死的，只能按照启动->发动引擎->鸣笛->停车的顺序执行，显然不能知足全部人的需求。好比张三习惯启动后按一下喇叭，而李四习惯先按下喇叭在启动，这就致使上面的程序不能同时知足两人的要求。全部，咱们这里要实现可让客户本身定义执行顺序的需求。设计模式
咱们来整理一下思路，首先，无论客户的需求是什么样子的，汽车的功能是不会变的，永远都有启动、发动引擎、鸣笛和停车的功能，因此，咱们能够把这些共有的行为抽象到父类定义，具体怎么实现交给子类去重写便可。而后，因为张三和李四想要按不一样的顺序执行汽车的四个方法，因此，咱们能够提供一个有序的集合，里面存放用户自定义的方法执行顺序，最后遍历这个有序集合不就能够了。好，开始设计类图：微信
抽象父类中定义一个成员变量 sequence 保存方法的执行顺序，由客户去设置它的值。具体源代码以下。架构
抽象父类AbstractCar：ui
子类只需各自实现汽车的四个功能便可。代码以下：spa
客户调用端代码：.net
上面的程序已经知足了随意调整汽车启动顺序的需求，但细想一下，是否是以为有些瑕疵？每一个客户买完车以后都要本身去设置它的启动顺序，好比说这个设置操做很复杂，必须通过专业的培训才能学会如何设置，那不是让客户发狂吗。因此，咱们想要达到的效果是客户须要什么启动顺序直接告诉造车厂的人，在建造汽车的时候就把这个顺序设置好就好了。因而，建造者模式就闪亮登场了。设计
建造者模式
建造者模式也叫生产器模式，它是将一个复杂对象的构建与它的表示分离，使得一样的构建过程能够建立不一样的表示。建造者模式有一个通用的类图，以下：3d
建造者模式中，有以下4个角色：orm
1. Product 产品类，一般是实现了模板方法模式，也就是有模板方法和基本方法。就像上面例子中的汽车类。关于模板方法模式能够阅读个人上篇文章“设计模式篇——模板方法模式详解”。对象
2. Builder 抽象建造者，它是规范产品的组件，通常是由子类实现。
3. ConcreteBuilder 具体建造者，实现抽象 Builder 定义的全部方法，而且返回一个组件好的对象。
4. Director 导演类，负责安排已有模块的顺序，而后告诉 Builder 开始建造。
建造者模式的通用代码也很简单，先看 Product 产品类，一般它是一个组合或继承产生的类：
抽象建造者 Builder 代码：
其中，setPart 方法就是零件的配置，什么是零件？其余的对象，得到一个不一样的零件，或者不一样的装配顺序就可能产生不一样的产品。
具体建造者 ConcreteBuilder 代码：
注意：若是有多个产品类，就要有多个建造者，并且这多个产品类实现了相同的接口或父类。
导演类 Director 代码：
导演类起到封装的做用，避免高层模块深刻到建造者内部的实现类。当建造者模式比较庞大时，导演类能够有多个。
基于建造者模式改造例子代码
接下来，咱们就一块儿基于建造者模式改造上面生产汽车的代码。首先改造咱们的类图：
其中，AbstractCar 及其子类 Car一、Car2 代码不变，咱们只看新增的类的代码。
抽象汽车建造类 CarBuilder 代码以下：
不一样执行顺序的车辆模型的组装者 Car1Builder、Car2Builder代码以下：
下面是直接与客户交互，获取具体车辆模型的导演类的代码：
OK，改造完成，调用方使用起来是否是方便多了，只须要获取一辆车，而后就能够运行了。
建造者模式的使用场景
建造者模式具备如下优势：
1. 封装性好，客户端没必要知道内部产品的实现细节。
2. 建造者独立，容易扩展。
3. 便于控制细节风险。
知道了它的优势，再来讲说何时用建造者模式：
1. 相同的方法，不一样的执行顺序，产生不一样的事件结果时，能够采用建造者模式。
2. 多个部件或零件，均可以装配到一个对象中，可是产生的运行结果又不相同时，则可使用该模式。
3. 产品类很是复杂，或者产品类中的调用顺序不一样产生了不一样的效能，这个时候使用建造者模式很是合适。
4. 在对象建立过程当中会使用到系统中的一些其余对象，这些对象在产品对象的建立过程当中不易获得时，也能够采用建造者模式封装该对象的建立过程。
点个关注吧，我会持续更新更多干货~~
本文分享自微信公众号 - Java架构成长之路（K469785635）。
若有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一块儿分享。