建造者模式(Builder Pattern)

建造者模式(Builder Pattern)

它能够将多个简单的对象一步一步构建成一个复杂的对象。

意图：将一个复杂的构建与其表示相分离，使得一样的构建过程能够建立不一样的表示。

主要解决：主要解决在软件系统中，有时候面临着"一个复杂对象"的建立工做，其一般由各个部分的子对象用必定的算法构成；因为需求的变化，这个复杂对象的各个部分常常面临着剧烈的变化，可是将它们组合在一块儿的算法却相对稳定。

什么时候使用：一些基本部件不会变，而其组合常常变化的时候。

如何解决：将变与不变分离开。

关键代码：建造者：建立和提供实例，导演：管理建造出来的实例的依赖关系。

应用实例： JAVA 中的 StringBuilder等。

优势： 一、建造者独立，易扩展。 二、便于控制细节风险。

缺点： 一、产品必须有共同点，范围有限制。 二、如内部变化复杂，会有不少的建造类。

使用场景： 一、须要生成的对象具备复杂的内部结构。 二、须要生成的对象内部属性自己相互依赖。

注意事项：与工厂模式的区别是：建造者模式更加关注与零件装配的顺序。

　　在咱们实际编程开发过程当中须要调用许多前人已经写好的类或接口来完善咱们某些特殊的需求，这就比如咱们去餐馆里吃饭（开发），点了一桌合家欢套餐（需求），桌上的饭菜里面一定有肉食，蔬菜类，主食，汤类等等（pojo，JavaBean，entity等），咱们不关心饭菜是怎样制做的（底层代码的具体实现逻辑和 数据），咱们只管吃喝玩乐（调用和吐槽）。大多数人并无耐心和精力去肯定每个菜品的选择，套餐无疑是一个简单方便效率高的选择，这时候若是餐馆经理（director）告诉咱们有“奢华套餐”和“普通套餐”或其余什么套餐（封装成类或接口）等多种选择，咱们会根据自身条件和需求自主选择要哪一个套餐。这个过程当中，餐馆经理（director）已经将各个菜品封装好，而后端上桌子供咱们享受，不管奢华套餐仍是普通套餐都还有肉食，蔬菜类，主食，汤类等要素。

　　这无形中提升了餐馆的营业效率和压缩顾客的点餐时间成本，餐馆内部分工方面，厨师仍是作原来的菜（基础类工厂），新产生的职位拼菜工（director内部方法）将菜品封装（调用封装类）。若是餐馆须要一位能作不一样口味的厨师，能作更多的菜，产生更多的套餐，那咱们只需向餐馆经理（director）提意见就行了.

　　最后，我本身也蒙圈了，这个比喻有些许不恰当的地方，初出茅庐，还请大神指正。以上只是我本身的理解。总之建造者模式的精髓仍是告诫人们不要重复造轮子，让你们享受更便捷的开发环境。

 

 

 

 

参考资料：http://www.runoob.com/design-pattern/builder-pattern.html

https://blog.csdn.net/u010102390/article/details/80179754