建造者模式-公开课件.pptVIP

本章目标 理解建造者模式 掌握建造者模式应用场景 引子 在软件系统中，有时候面临着“一个复杂对象”的创建工作，其通常由各个部分的子对象用一定的算法构成；由于需求的变化，这个复杂对象的各个部分经常面临着剧烈的变化，但是将它们组合在一起的算法确相对稳定。如何应对这种变化？如何提供一种“封装机制”来隔离出“复杂对象的各个部分”的变化，从而保持系统中的“稳定构建算法”不随着需求改变而改变？ 找模型 例如快餐店制作儿童餐。典型的儿童餐包括一个主食，一个辅食，一杯饮料和一个玩具（例如汉堡、炸鸡、可乐和玩具车）。这些在不同的儿童餐中可以是不同的，但是组合成儿童餐的过程是相同的。无论顾客点的是汉堡，三名治还是鸡肉，过程都是一样的。柜台的员工直接把主食，辅食和玩具放在一起。这些是放在一个袋子中的。饮料被倒入杯中，放在袋子外边。这些过程在相互竞争的餐馆中是同样的。 建造者模式 意图 将一个复杂的构建与其表示相分离，使得同样的构建过程可以创建不同的表示 去KFC店买套餐 客户端：顾客。想去买一套套餐（这里面包括汉堡，可乐，薯条），可以有1号和2号两种套餐供顾客选择。 指导者角色：收银员。知道顾客想要买什么样的套餐，并告诉餐馆员工去准备套餐。 建造者角色：餐馆员工。按照收银员的要求去准备具体的套餐，分别放入汉堡，可乐，薯条等。 产品角色：最后的套餐，所有的东西放在同一个盘子里面。 买套餐过程 客户创建Derector对象，并用它所想要的Builder对象进行配置。顾客进入KFC店要买套餐，先找到一个收银员，相当于创建了一个指导者对象。这位收银员给出两种套餐供顾客选择：1普通套餐，2黄金套餐。 具体实现 产品（套餐）类 具体实现 指导者通知建造器。收银员（指导者）告知餐馆员工准备套餐。这里我们准备套餐的顺序是：放入汉堡，可乐倒入杯中，薯条放入盒中，并把这些东西都放在盘子上。这个过程对于普通套餐和黄金套餐来说都是一样的，不同的是它们的汉堡，可乐，薯条价格不同而已 具体实现 指导者代码： 具体实现 建造者处理指导者的要求，并将部件添加到产品中。餐馆员工（建造者）按照收银员要求的把对应的汉堡，可乐，薯条放入盘子中。这部分是建造者模式里面富于变化的部分，因为顾客选择的套餐不同，套餐的组装过程也不同，这步完成产品对象的创建工作 具体实现 具体建造者：普通套餐 具体实现 具体建造者：黄金套餐 具体实现 客户从建造者检索产品。从餐馆员工准备好套餐后，顾客再从餐馆员工那儿拿回套餐。这步客户程序要做的仅仅是取回已经生成的产品对象 具体实现 客户端调用： 实现要点 1、建造者模式主要用于“分步骤构建一个复杂的对象”，在这其中“分步骤”是一个稳定的算法，而复杂对象的各个部分则经常变化。 2、产品不需要抽象类，特别是由于创建对象的算法复杂而导致使用此模式的情况下或者此模式应用于产品的生成过程，其最终结果可能差异很大，不大可能提炼出一个抽象产品类。 3、创建者中的创建子部件的接口方法不是抽象方法而是空方法，不进行任何操作，具体的创建者只需要覆盖需要的方法就可以，但是这也不是绝对的，特别是类似文本转换这种情况下，缺省的方法将输入原封不动的输出是合理的缺省操作。 4、前面我们说过的抽象工厂模式（Abtract Factory）解决“系列对象”的需求变化，Builder模式解决“对象部分”的需求变化，建造者模式常和组合模式（Composite Pattern）结合使用。 特点 1、建造者模式的使用使得产品的内部表象可以独立的变化。使用建造者模式可以使客户端不必知道产品内部组成的细节。 2、每一个Builder都相对独立，而与其它的Builder无关。 3、可使对构造过程更加精细控制。 4、将构建代码和表示代码分开。 5、建造者模式的缺点在于难于应付“分步骤构建算法”的需求变动。 应用场景 以下情况应当使用建造者模式：1、需要生成的产品对象有复杂的内部结构。2、需要生成的产品对象的属性相互依赖，建造者模式可以强迫生成顺序。3、 在对象创建过程中会使用到系统中的一些其它对象，这些对象在产品对象的创建过程中不易得到。 应用场景1、 RTF文档交换格式阅读器。2、 .NET环境下的字符串处理StringBuilder，这是一种简化了的建造者模式。3、 我曾在一个银行交易类项目中遇到了这个问题，一个产品的定价计算模型有 N多种，每个模型有固定的计算步骤，计算非常复杂，项目中就使用了建造者模式； 本课程版权归北风网所有 欢迎访问我们的官方网站 * 北风网项目培训 讲师：石曼迪 设计模式——建造者模式 public class Food { Hashtable food = new Hashtable(); pub