标签：
不要小看炒菜这件小事上，想要上一道佳肴，那是需要循规蹈矩，步步小心的。我相信你肯定在外面吃过没放盐的快餐，吃过放多了盐的快餐.....既然炒菜是一个如此复杂的过程，又必须循规蹈矩，那为什么不给他一个死规定呢？如果谁没有按照规定做事，就进行对应的提醒警告。这就是建造者模式的由来，限制规则步骤，但是开发规则细节。比如说盛菜之前必须放盐，那么规定一定要放盐，具体放多少自己论情况而定。
如果你需要将一个复杂对象的构建与它的表示（构建具体过）分离，使得同样的构建过程可以创建不同的表示的意图时，建造者模式就出现了，这个模式又称为生成器模式，从名字就可以知道，他的目的是为了构建（生成）一个对象，一个创建大体过程相同，但是具体细节不同的对象。
复杂的炒菜过程忘记了放盐
没有很注意，如果哪位同学觉得哪里用上了，可以补充
1）Director：指挥者，他来定义这个复杂对象的创建流程
2）Builder：抽象构建角色，他是定义每一个规矩细节，也就是声明构建这个对象需要哪些必要的规矩方法
3）ConcreteBuilder：具体构建者，他实现了Builder的每一个规矩，因为方法实现的多样化从而造就了各种不同的对象
建造模式：将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示；
这些复杂对象的内部构建的顺序通常是稳定的，步骤的多少也是确定的，如果是那些不稳定经常发生变化的复杂对象，那么这个设计模式将会是一个未被开放封闭原则的错误！
建造者模式的好处是使得建造代码与表示代码分离，由于建造者隐藏了该产品是如何组装的，所以若需要改变一个产品的内部表示，只需要顶一个一个具体的建造者。
建造者模式是在当创建复杂对象的算法应该独立于该对象的组成部分以及他们的装配方式时适用的模式。
建造者模式可以将一个产品的内部表象与产品生成过分割开来，从而可以使一个建造过程生成具有不同内部表象的产品对象。
采用建造者模式感觉很大的优点就是：
1）接口已经声明，没有实现的具体构建者都不能通过编译，那么步骤不会缺失（空实现也算实现）
2）不同对象的创建容易扩展，因为建造与表示分离，所以，可以很好的扩展不同的对象。
相比其他设计模式，这个模式其实有模板方法模式有点相似，都是一个固定的过程中，实现不同的细节；
标签：
原文地址：http://my.oschina.net/heweipo/blog/465769
