打印结果：
Building book framework
Adding chapter item1
Adding chapter item2
Adding chapter item3
Adding chapter item4
book: [item1, item2, item3, item4]
Building magazine framework
Adding chapter item1
Adding chapter item2
Adding chapter item3
Adding chapter item4
magazine: [item1, item2, item3, item4]
从建造模式的工作流程来看，建造模式将产品的组装“外部化”到了建造者角色中来。这是和任何正规的工厂模式不一样的――产品的创建是在产品类中完成的。
建造模式可以使得产品内部的表象独立变化。在原来的工厂方法模式中，产品内部的表象是由产品自身来决定的；而在建造模式中则是“外部化”为由建造者来负责。这样定义一个新的具体建造者角色就可以改变产品的内部表象，符合“开闭原则”。
建造模式使得客户不需要知道太多产品内部的细节。它将复杂对象的组建和表示方式封装在一个具体的建造角色中，而且由指导者来协调建造者角色来得到具体的产品实例。每一个具体建造者角色是毫无关系的。
建造模式可以对复杂产品的创建进行更加精细的控制。产品的组成是由指导者角色调用具体建造者角色来逐步完成的，所以比起其它创建型模式能更好的反映产品的构造过程。
建造模式中很可能要用到组成成品的各种组件类，对于这些类的创建可以考虑使用工厂方法或者原型模式来实现，在必要的时候也可以加上单例模式来控制类实例的产生。但是要坚持一个大前提就是要使引入的模式给你的系统带来好处，而不是臃肿的结构。
建造模式在得到复杂产品的时候可能要引用多个不同的组件，在这一点上来看，建造模式和抽象工厂模式是相似的。可以从以下两点来区分两者：创建模式着重于逐步将组件装配成一个成品并向外提供成品，而抽象工厂模式着重于得到产品族中相关的多个产品对象；抽象工厂模式的应用是受限于产品族的（具体参见《深入浅出工厂模式》），建造模式则不会。由于建造模式和抽象工厂模式在实现功能上相似，所以两者使用的环境都比较复杂并且需要更多的灵活性。
组合模式中的树枝构件角色（Composite）往往是由多个树叶构件角色（Leaf）组成，因此树枝构件角色的产生可以由建造模式来担当。