BlogJava-清清流水-文章分类-设计模式

《设计模式》之Java解读--桥接Bridge

qinysong — Fri, 11 Aug 2006 07:54:00 GMT

摘要: 1、核心意图：将抽象部分和实现部分分离，使它们都可以独立的变化。该模式的目标是通过把高层的抽象和底层的实现分开，分别构建自己的类层次结构，并通过实现部分的接口将两部分进行桥接，从而达到高层抽象和底层实现可以独立的方便扩展的目的。其核心是分离，和委托。 2、身边实例： Java语言的一个非常重要的特点是平台的无关性，对于一般的高级语言... 阅读全文

qinysong 2006-08-11 15:54 发表评论

《设计模式》之Java解读--适配器Adapter

qinysong — Fri, 11 Aug 2006 07:53:00 GMT

摘要: 1、核心意图：将一个类的接口转换成客户希望的另外一个接口，从而使得原本由于接口不兼容而不能一起工作的类可以一起工作。该模式的目标是通过一个代理（这里是Adapter），在原来的类（Adaptee）和客户（Client）之间进行协调，从而达到兼容的目的。其核心是解决一致性的问题。 2、身边实例：在我们实际生活中也... 阅读全文

qinysong 2006-08-11 15:53 发表评论

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

qinysong — Fri, 11 Aug 2006 07:45:00 GMT

核心意图：

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 的配置文件形式的依赖注入形式所代替。

qinysong 2006-08-11 15:45 发表评论

GOF设计模式-创建型模式理解与思索（二）（Factory Method分析）

qinysong — Fri, 11 Aug 2006 07:38:00 GMT

Factory Method模式相对于其他创建型模式，应该是最简单、最容易实现的模式，该模式定义了一个用于创建对象的接口，而让子类决定实例化哪一个类，这样就将实例化的过程延迟到了子类，从而提高了对象创建的灵活性，在这里一个最核心的特征就是为子类提供了一个挂钩。

但是，该模式有一个潜在的缺陷，就是客户可能仅仅为了创建一个特定ConcreteProduct对象而不得不创建Creator的子类，这样，当客户端除了需要一个新的ConcreteProduct而对Creator没有别的新要求时，就会增加维护新产生的Creator类层次负担。通过分析我觉得在如下三个场景中比较适合采用Factory Method模式：

1、Abstract Factory内部。Abstract Factory（抽象工厂）模式可以通过Factory Method实现，此时抽象工厂内的每个创建一类对象的方法就可以是一个Factory Method。结构图如下：

2、框架应用。因为框架给特定应用提供了基础机构，而它（框架）对特定应用的细节是不可知的，所以当在框架中必须创建某种应用对象时，就可以通过工厂方法进行临时填充，具体应用对象的创建通过框架子类重定义该挂钩接口来实现，具体细节描述见该模式的动机部分，结构图如下：

3、在类层次中创建类相关对象。如果存在一个类层次，这个类层次中的每个类都需要一个相似但却略有不同的类于自己关联，这时关联类可以由自己负责和管理，如该模式的效果部分中的图形操作对象类层次。以及jdk集合工具包中迭代器的生成，在jdk集合类层次中，每个具体集合类都有一个与之相对应的迭代器（Iterator）类，具体的迭代器对象就可以由各个集合类负责产生，结构图如下：

继续深入

在上一篇blog中，我提到创建型模式抽象了对象的实例化过程，而这种抽象化的实现方式大致分为：对象委托、类继承和实例注入三种，并且我把Factory Method模式归入到了通过类继承方式，这与GOF设计模式中的划分——Factory Method 为对象创建型模式有些不一致。

通过对GOF的《设计模式-可复用面向对象软件的基础》的学习和理解，我觉得在一些时候将Factory Method 模式归入类创建型模式可能会更为贴切和容易理解，原因如下：

第一、“类创建型模式将对象的部分创建工作延迟到子类中，而一个对象创建型模式将它延迟到另一个对象中”（引言1.5节），Factory Method模式正式通过在类中定义一个用于创建对象的接口，而让子类通过重新定义该接口（也可能使用父类实现）来决定实例化哪一个类。这种通过父类定义、子类实现的方式正是类的继承机制。

第二、我们可以通过Template Method（模板方法-类行为型模式）来进一步说明，Template Method定义了一个操作中算法的骨架，而将一些步骤延迟到子类中，从而使得子类可以不改变算法的结构既可重定义该算法的某些特定步骤。这与Factory Method的意图（定义一个用于创建对象的接口，而让子类来决定实例化哪一个类，从而使一个类的实例化延迟到子类，给子类带来了灵活性）从层次的角度来说正好相同，而不同的只是Template Method 延迟的是操作行为，Factory Method 延迟的是实例化对象。

其实，将某个模式分为对象模式还是类模式，我觉得并不是很严格，具体分法只是根据观察的角度不同而已。比如对于书中该模式的动机部分中所讲的示例——一个文档应用框架，和代码程序部分中的迷宫的创建，我觉得用类创建型模式理解就会好一些；而对于书中该模式的效果部分中提到的创建图形操作对象，我觉得用对象创建型模式理解会好一些。通过分析总结就是：如果创建的对象是自己用，那就看作类创建型模式理解较好；如果创建的对象是提供给外界对象用，那就看作对象创建型模式理解较好。

qinysong 2006-08-11 15:38 发表评论

GOF设计模式-创建型模式理解与思索（一）（Abstract Factory 和Builder）

qinysong — Fri, 11 Aug 2006 07:30:00 GMT

最近又在翻看GOF的《设计模式-可复用面向对象软件的基础》一书，发现经典就是经典，每次都有新的体验和收获，所以这次把理解和心得写下来，以备学习和交流。

创建型模式抽象了实例化过程，他帮助一个系统独立于如何创建、组合和表示他的那些对象。在Gof 23种经典模式中，主要通过以下方式对实例化过程进行分离和抽象：

1、对象委托。即是将对象的创建委托给专门的工厂对象，这样对于工厂所创建的对象就可以集中进行管理，并向客户端隐藏实际类型信息，客户端所知道的只是所使用（包含）对象的借口，这样当需要对这些对象进行类型、结构调整时就可以非常的方便且统一。如Abstract Factory 和Builder。

2、类继承。即通过在父类中定义创建对象的接口，从而当子类在需要的时候就可以通过重新实现该接口来创建其他类型的对象。如Factory Method。

（注：Factory Method在GOF设计模式中归在对象型模式中，我下一步再继续讨论）

3、实例注入。这种方式的实质是客户端不需要知道所创建/使用的对象的具体类型，而只需要知道在实际运行的时候会得到这些对象的原型，当需要创建对象时仅克隆所得到的原型即可。如Prototype。

至于以上三种方式没有包括的Singleton，我觉得Singleton模式的主要目标并不是对象类型的封装分离，而是为对象的唯一性提供一种保障，且提供一个全局的访问点。

各种模式的相互联系和区别：

1、 Abstract Factory 和 Builder 模式的联系和区别：

抽象工厂和生成器两种模式都是通过委托机制，将创建对象的任务委托给一个其他对象来完成，而向外只提供一个接口。

但是两者的区别还是很大的。

Abstract Factory提供了一个创建一些列相关或相互依赖对象的接口，而无需指定具体的类。它的核心是一系列相关或相互依赖对象，并且这一系列对象可能会因为某种系统属性而变化，比如GOF该模式动机中提到的创建一个支持多种视感标准的用户界面工具包，该工具包中的窗口组件（输入框、滚动条、按钮等）按不同的视感风格要定义不同的外观和行为，这样就不能把这些具体风格相关的组件类型信息硬编码到应用中，而最好应该在应用中只使用抽象组件类型，具体风格相关类型组件的创建封装到抽象工厂的实现中。其他示例如：1，在GOF该模式代码示例中所示的创建不同类型迷宫，不同类型的迷宫组件的创建也是由抽象工厂的实现完成；2，论坛应用中针对不同数据库（sql server或my sql）需要不同的DAO实现，这些DAO也可以通过抽象工厂的具体实现而同一管理。

结构图如下：

Builder的意图是将一个复杂对象的创建和它的表示分离，从而使相同的构建过程可以创建不同的表示。它的核心是针对一个复杂对象的创建，而将创建的过程进行分解分离，比如对一辆汽车的创建，我们就可以将其分解为模型的设计、汽车组件加工、汽车组装三个过程；一幢大厦的建造，我们也同样可以分解为图纸设计、建材选购、建筑施工三个阶段。这样通过分解后，就可以相应对立的对某个阶段/过程进行修改、替换，从而在其他阶段/过程相同的情况下有着不同的对象生成。

结构图如下：

此外对于较复杂对象的创建，Builder模式中也可以引入Abstract Factory模式来为自己创建基本的组件对象，比如我们去配一台台式机，我们就可以把组装电脑的店家看作一个Builder创建器，它根据我们的需要（配置参数）为我们装配所需的电脑，同时电脑所需的部件他又是通过销售商（可以看作抽象工厂的代理）获取，而不是自己创建。

现实世界对象结构图如下：

这个结构图可能会让人比较奇怪，看上去它和GOF中Builder模式的结构图有些不一样，这个结构图缺少Director角色，其实这个区别是很好理解的，因为这个结构图只是现实世界的对象模型，而我们传入的ConfigListing（配置清单）的解析如果用程序来实现，可能就需要增加解析器的角色了。

根据以上理解，所以两种模式的差异就比较明显，Abstract Factory 模式针对一系列对象的创建，这一系列对象受某一系统属性影响；Builder 模式针对一个复杂对象的创建过程，对过程分解，从而可以使各阶段相互独立，使得相同的构建过程可以创建不同的表示，亦可通过不同的构建过程创建由相同表示所构成的不同对象。

qinysong 2006-08-11 15:30 发表评论