建造者模式(Builder Pattern)
它可以将多个简单的对象一步一步构建成一个复杂的对象。
意图：将一个复杂的构建与其表示相分离，使得同样的构建过程可以创建不同的表示。 主要解决：主要解决在软件系统中，有时候面临着"一个复杂对象"的创建工作，其通常由各个部分的子对象用一定的算法构成；由于需求的变化，这个复杂对象的各个部分经常面临着剧烈的变化，但是将它们组合在一起的算法却相对稳定。 何时使用：一些基本部件不会变，而其组合经常变化的时候。 如何解决：将变与不变分离开。 关键代码：建造者：创建和提供实例，导演：管理建造出来的实例的依赖关系。 应用实例： JAVA 中的 StringBuilder等。 优点： 1、建造者独立，易扩展。 2、便于控制细节风险。 缺点： 1、产品必须有共同点，范围有限制。 2、如内部变化复杂，会有很多的建造类。 使用场景： 1、需要生成的对象具有复杂的内部结构。 2、需要生成的对象内部属性本身相互依赖。 注意事项：与工厂模式的区别是：建造者模式更加关注与零件装配的顺序。
在我们实际编程开发过程中需要调用许多前人已经写好的类或接口来完善我们某些特殊的需求，这就好比我们去餐馆里吃饭（开发），点了一桌合家欢套餐（需求），桌上的饭菜里面必定有肉食，蔬菜类，主食，汤类等等（pojo，JavaBean，entity等），我们不关心饭菜是怎样制作的（底层代码的具体实现逻辑和 数据），我们只管吃喝玩乐（调用和吐槽）。大多数人并没有耐心和精力去确定每一个菜品的选择，套餐无疑是一个简单方便效率高的选择，这时候如果餐馆经理（director）告诉我们有“奢华套餐”和“普通套餐”或其他什么套餐（封装成类或接口）等多种选择，我们会根据自身条件和需求自主选择要哪个套餐。这个过程中，餐馆经理（director）已经将各个菜品封装好，然后端上桌子供我们享受，无论奢华套餐还是普通套餐都还有肉食，蔬菜类，主食，汤类等要素。
这无形中提高了餐馆的营业效率和压缩顾客的点餐时间成本，餐馆内部分工方面，厨师还是做原来的菜（基础类工厂），新产生的职位拼菜工（director内部方法）将菜品封装（调用封装类）。如果餐馆需要一位能做不同口味的厨师，能做更多的菜，产生更多的套餐，那我们只需向餐馆经理（director）提意见就好了.
最后，我自己也蒙圈了，这个比喻有些许不恰当的地方，初出茅庐，还请大神指正。以上只是我自己的理解。总之建造者模式的精髓还是告诫人们不要重复造*，让大家享受更便捷的开发环境。
参考资料：http://www.runoob.com/design-pattern/builder-pattern.html