跟我学软件系统模块设计中的对象职责分配模式创建者模式.ppt

对象职责分配模式---创建者模式 对象职责分配模式---创建者模式 在本讲您能了解如下内容 什么是创建者模式 为什么需要创建者模式 创建者模式的主要作用 创建者模式的应用示例 GOF模式中的创建者模式 1、创建者模式----指导如何进行“创建对象”的职责分配 （1）它指导开发人员如何决定创建对象的职责分配 在利用OOP编程时，开发人员应该决定“谁”应该来负责产生类的对象实例----对应于GoF设计模式系列里的“工厂模式”中的“工厂类”。 而避免在系统中的不同模块都涉及对该类的对象进行对象实例化，从而使得藕合关系遍及整个系统中的各个不同功能模块。 （2）选择创建者的基本依据 2、为什么需要创建者模式（Creator） （1）创建者模式能够正确地指导创建耦合关系 （2）减少不必要的由于创建对象而产生的耦合关系 因为如果一个类创建了另一个类的对象实例，那么这两个类之间就产生了耦合，也可以说产生了依赖关系。 依赖或耦合本身是没有错误的，但是它们带来的问题就是在以后的系统维护中会产生相关的连锁反应形式的修改，开发人员应该尽可能地减少这样无意义的藕合，当然必要的耦合是必须要的。 正确地创建耦合关系，不要随便建立类之间的依赖关系。为此，要遵守GRASP中的创建者模式规定的基本原则，凡是不符合以上条件的情况，都不能随便用A创建B（请见前面的说明）。 当应用“信息专家模式”为类分配职责工作后，不得不考虑的另一个问题——谁来创建这些对象？ 3、创建者模式的作用可以概括为如下两点 （1）封装创建逻辑的细节 因为有些对象的创建，绝不仅仅是new一个对象那么简单-----比如，数据库连接对象、基于JNDI形式下的DataSource对象、报表等复合对象的创建等。 此时我们可以通过创建者模式来封装复杂的对象创建逻辑的细节。 （2）封装创建逻辑的变化 当对象的创建逻辑发生变化时，尽可能使客户端的代码不需要进行修改，或尽量少修改。 您了解GOF中的Builder模式？ 您了解GOF中的Factory模式吗？ 4、创建者模式应用示例一 （1）网上商店系统中的商品对象的创建问题 由于订单（Order）是商品（Goods）的容器，同时订单持有初始化商品的各个方面的数据信息 所以订单Order类和商品Goods类的耦合关系是正确的且没办法避免的；但不应该与用户信息UserInfo类产生藕合关系。 （2）正确地选择对象的创建者 基于创建者模式的原则，应该由订单类来创建商品类的对象，并提供getGoods方法为其它的类提供商品对象。 这样的设计结果将使得其它的类不需要了解对商品对象实例创建的实现细节，达到封装创建逻辑的细节设计目标。 当然，也可以单独为商品信息类的对象创建提供一个专门的工厂类进一步隔离。 5、利用创建者模式实现封装创建逻辑的变化应用示例 （1）网上商城系统中的多数据源下的数据连接对象的创建问题——下面为不良好的设计 （2）为此，有必要封装对象创建逻辑的细节和变化 本示例仅仅是数据库的类型发生了变化，就需要修改程序中所有的“new”这样的语句以便能够达到从一种数据源切换到另一种数据源。 （3）如何能够封装对象创建逻辑的细节和变化——工厂类 您了解GOF中的Factory模式吗？ 问题：当数据源发生变化时，开发人员不是也要修改工厂类吗？ 是的！当需求方式改变时，开发人员很难避免不修改程序, 但是要尽量做到只修改一处（减少维护的工作量）！这就是GOF中的工厂模式提出的理由或者价值！ 6、GOF模式中存在许多与创建者模式类似的设计模式 （1）GOF模式中的创建者模式 在GOF的设计模式的划分中，把与实现对象的实例化相关的模式称之为“创建型模式”----而工厂模式为创建型模式中的一种形式 （2）在GOF 创建型模式中的各个具体的其它模式 单例模式（Singleton Pattern） 解决的是实体对象的个数问题，其它的都是解决new所带来的耦合关系问题。 工厂方法模式（Factory Pattern） 在工厂方法中，工厂类成为了抽象类，其实际的创建工作将由其具体子类来完成； 工厂方法的用意是定义一个创建产品对象的工厂接口，将实际创建工作推迟到子类中去，强调的是“单个对象”的变化。 抽象工厂模式（Abstract Factory） 抽象工厂是所有工厂模式中最为抽象和最具有一般性的一种形态；抽象工厂可以向客户提供一个接口，使得客户可以在不必指定产品的具体类型的情况下，创建多个产品族中的产品对象，强调的是“系列对象”的变化。 Builder模式 将构建复杂对象的“过程”和它的“部件”解耦 7、创建者模式的价值 使用创建者模式是为了提高代码的可维护性，也就是提高未来系统