GOF设计模式-创建型模式理解与思索（三）（Prototype分析）

欢迎转载，请注明出处。

核心意图：

        Prototype模式通过原型实例指定创建对象的种类，并通过拷贝这些原型创建新的对象。其核心是采用注入的方式，隔离对象客户和对象之间的关系，对象客户只需要知道自己所需要的对象可以通过复制外界传给自己的原型就可以得到，而具体是什么特殊的类型不需费心。

 

模式分析：

　　在我们日常生活中，也经常会碰到这种Prototype模式的类似情形，比如小区门口配钥匙的，当顾客需要一把新钥匙时，配钥匙师傅只需要用原来的钥匙，在磨具中进行复制就可以生成一把新的钥匙，顾客要配的钥匙配钥匙师傅事先不要关心，只要保证顾客的钥匙是可以通过磨具进行加工的就可以（即实现Clone接口）。

 

      在动机一节中GOF通过定制一个通用的图形编辑器框架，增加一些表示音符、休止符、五线谱一类的新对象来构建了一个乐谱编辑器。该乐谱编辑器的结构有些类似于Factory Method模式动机一节中介绍的定制文档应用框架为绘图文档应用系统，应用框架通过抽象类Application和Document来维护文档的操作关系，在框架中Application必须能够能够创建Document类的实例，但是实际应用程序的Document又是特定于应用系统的，是在框架中所不能知道和确定的，因此为了将创建过程延迟到子类，框架引入了Factory Method模式，通过重新定义Application的子类工厂方法来创建正确的文档Document类对象。

      但是所不同的是该图形编辑器框架可能需要同时编辑多种类型的图形，而不像文档应用框架只负责管理一种类型的文档，因此如果也采用文档应用框架所用的工厂方法Factory Method模式，就会出现一个和图形对象类层次平行的工厂Creator类层次，而这个类层次仅仅是所创建的对象不同而已，并且当增加新的图形对象时也要相应增加工厂的类层次，不便于维护。

 

    由于这种区别，在这个图形编辑器框架中采用了Prototype原型模式，通过为工具对象传入所要操作的图形对象，来告诉工具对象，你只要复制该对象并使用复制对象就可以，不需要关心它是什么具体类型。这样就隔离了对象客户和对象之间的关系，从而既省去了创建Creator的平行类层次，又在增加新的图形对象时，可以通过动态注册原型对象加以支持。

 

Abstract Factory、Factory Method和Prototype适用性比较：

       1、Abstract Factory 模式适合创建一系列相关或相互依赖对象，并且系统可能会有多个这样的系列，并在系列间进行切换。结构图如下：

 

       

       2、Factory Method模式适合用在两方面，第一是框架中，并且该框架只需维护管理一类框架抽象对象的特定应用子对象；第二是一个平行类层次中，并且该平行类层次有一个对应平行的相关类层次。结构图如下所示：

 

    （框架中抽象对象对特定应用子对象的创建）

 

 

    （类层次对象创建相关类层次对象）

 

      3、Prototype模式适合框架中，并且该框架维护和管理特定于应用的多种同类对象。结构图如下：

 

Prototype在Java中的使用：

       由于Java动态类加载的完美实现，并且随着Spring等业务层框架的依赖注入技术发展，Prototype模式实现形式也可以进一步理解，比如在Spring中，资源配置文件也可以理解为是原型模式的实现形式，只是为客户传入的不是类实例，而是具体类的全局名称，在运行时通过依赖注入机制再进行实例化，如下代码片断所示：

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE beans PUBLIC "-//SPRING//DTD BEAN//EN" "http://www.springframework.org/dtd/spring-beans.dtd">
<beans>
  <bean id="dataSource" class="org.springframework.jndi.JndiObjectFactoryBean">
    <property name="jndiName"><value>java:comp/env/jdbc/frame1DataSource</value></property>
  </bean>
  <bean id="userDAO" class="com.qinysong.persistence.user.jdbc.UserDAOImpl">
    <property name="dataSource">
      <ref local="dataSource"/>
    </property>
  </bean>
  <bean id="addressDAO" class="com.qinysong.persistence.user.jdbc.AddressDAOImpl">
    <property name="dataSource">
      <ref local="dataSource"/>
    </property>
  </bean>
  <bean id="userManager" class="com.qinysong.service.user.UserManager">
    <property name="userDao">
      <ref local="userDAO"/>
    </property>
    <property name="addressDao">
      <ref local="addressDAO"/>
    </property>
  </bean>
</beans>

       由于这种配置方式的灵活，所以在以前应用中所经常用的Abstract Factory模式可以更好的被这个Prototype的配置文件形式的依赖注入形式所代替。