论坛首页 Java企业应用论坛

对结构型设计模式的理解

浏览 13945 次
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
作者 正文
   发表时间:2006-12-14  
在Gof设计模式中,对设计模式的主要分类为:1)创建型、2)结构型、3)行为型。创建型设计模式抽象了对象的实例化过程;结构型设计模式涉及到如何组合类和对象以获得更大的结构;行为型设计模式描述算法和对象间职责的分配。
 
那么,结构型设计模式到底如何对类和对象进行组合,以获得更大的结构,组合的指引是什么呢?Adapter/Bridge/…/Proxy七种模式只是结构型设计模式的七个实例,这七个实例的核心主题是什么呢?
通过分析,我觉得可以将结构型设计模式的主题用三个词概括:1)统一、2)概括、和3)分离。
 
1)统一:达到一致
“统一”描述了对象组合的一个主题,通过统一性便于客户使用和扩展,在Gof七种结构型设计模式中,可以归入该主题的有Adapter(适配器)、Composite(组合)模式。
 
Adapter通过将一个类的接口转换为客户希望的另一个接口,即统一Adaptee类接口到Target接口,以便于客户Client使用。
 
Composite模式统一基元对象和组合对象,从而建立一个“部分——整体”的类层次结构。通过这个结构,客户Client可以一致的使用各种类型的组件,包括基元组件和组合组件;此外对于新的组件,无论是新的基元还是新的组合组件,都可以自然的融入到该层次结构中,从而增强了可扩展性。
 
2)概括:提高抽象
“概括”也描述了对象组合的一个主题,它对一些对象进行抽象和提取,然后提供给客户使用,这样既便于客户使用,也便于对底层的被概括的对象进行扩展和维护。在Gof七种结构型设计模式中,概括为该主题的有Facade(外观)模式。
 
Facade模式为子系统中的一组对象提供一个高层接口,这个高层接口使得这个子系统更容易使用和维护。
 
3)分离:降低耦合便于扩展
分离可以说是很多模式的一个主题,不仅结构型模式,创建型/行为型设计模式中也有大量的以分离为主题的模式。通过分离可以解耦关联、增加各部分的独立性等等。在Gof七种结构型设计模式中,概括为该主题的有Bridge(桥接)、Decorator(装饰器)、Flyweight(享元)、和Proxy(代理)模式。
 
Bridge模式分离了抽象部分和实现部分,使两部分都可以独立的变化;
 
Decorator模式分离了被装饰的对象和各种用于装饰的状态和职责,从而可以在运行时灵活地对组件对象进行各种装饰;
 
Flyweight模式分离了大量小对象中的运行环境状态信息,从而使这些小对象可以共享;
 
Proxy模式通过提供代理,分离了客户Client和Subject对象,从而可以在中间提供一些辅助的功能和服务;
   发表时间:2006-12-14  
似乎上升到哲学了,呵呵
0 请登录后投票
   发表时间:2006-12-14  
几种结构型设计模式的对比

各种结构型设计模式由于或是采用类继承机制、或是采用对象组合方式实现,所以很多都具有一定的相似性,下面对比较相似的四组模式进行讨论

1、适配器Adapter VS 组合Composite
相似点:都为客户提供了一致性。
Adapter通过提供一致性使被适配组件Adaptee和目标组件Target兼容,从而使得这些组件可以一起使用;
Composite通过提供一致性使组合对象和单个对象对用户透明,用户可以一致的加以使用;

不同点:
1)效果不同:
Adapter主要针对不是一起开发的两个类,接口不兼容但是后面开发的类正好可以重用前一个类,为了能够重用,从而需要通过适配器Adapter进行适配;
Composite主要对一个部分-整体的类层结构进行组合,从而便于用户统一使用,以及增加组件的可扩展性,当需要增加新组件时,组件自动融入类层次结构。
2)结构不同:
Composite模式可以递归进行组合,以组合成非常复杂的组件;Adapter模式无递归需求。

类结构对比图如下:


2、组合Composite VS 装饰器Decorator
相似点:类结构相似、且都基于递归组合
Composite模式通过递归,组合基元组件为组合组件,再组合组合组件为复杂组合组件;
Decorator模式通过递归,可以动态地为对象增加多种额外功能或装饰;

不同点:
1)目的不同:
Composite模式表现部分和整体对象关系,统一基元对象和组合对象的使用;
Decorator模式为了动态的给一个对象添加一些额外的职责;

2)结构不同:
Composite模式中组合类可能由多个组件(包括基元和组合组件)组成,Composite通常通过容器包含其所容纳的对象;
Decorator模式一般只通过一个对象引用包含被装饰得对象,通常一次只装饰一个对象。

类结构对比图如下:


3、装饰器Decorator VS 代理Proxy
相似点:类结构相似,都提供了一定程度的间接性
Decorator和被装饰的组建ConcreteComponent有相同的接口Component,Proxy和被代理的对象RealSubject也有相同的接口Subject。
Decorator和Proxy通常都含有一个对象,Decorator对这个对象进行包装,Proxy对这个对象进行代理。

不同点:
1)目的不同:
Decorator动态的为一个对象添加一些额外的功能或属性;
Proxy为对象提供一个代理以便进行相应的控制和管理,如远程代理为不在同一地址空间的对象提供本地化代表、虚代理提供根据需要才创建开销很大的对象等等;

2)结构不同:
Decorator可以递归装饰,但Proxy一般并不进行递归代理
      
类结构对比图如下:


4、外观Facade VS 代理Proxy
相似点:都提供一定的间接性,Facade可以看作是一个子系统的代理Proxy
Facade通过为子系统提供一个门面,在用户和子系统之间建立一个方便简化的使用协议;
Proxy为被代理对象提供间接访问,从而根据不同的代理类型完成不同管理和控制任务;

不同点:
1)目的不同:
Facade模式为子系统提供一个高层接口,以达到简化子系统使用的目的;
Proxy为被代理对象提供间接访问,从而可以根据不同代理类型提供不同的任务;

结构不同:
Facade了解整个子系统,并把方法调用进行转发;Proxy模式只代理目标对象,且通常都提供一定的服务。

类结构对比图如下:


0 请登录后投票
   发表时间:2006-12-15  
看了对比,我觉得核心思想都一样,连方式也大同小异。
0 请登录后投票
   发表时间:2007-03-22  
noahgenius 写道
看了对比,我觉得核心思想都一样,连方式也大同小异。


其实我们谈论的设计模式(源GOF)的最终目标都是创建易于复用、易于维护的面向对象设计,且这些模式大多也只使用有限的几种技术,如类继承和对象组合,所以粗看起来可能都差不多,特别是结构和联结方式

但是对于每种模式都有其不同的针对点,都有不同的目的、不同的适用场景和考虑要素,所以这种差异性不能被表面的大同小异所掩盖
0 请登录后投票
   发表时间:2007-04-03  
希望能结合一个简单的实例进行讲解,不然的感觉太抽象了
0 请登录后投票
   发表时间:2007-04-03  
shenhai 写道
希望能结合一个简单的实例进行讲解,不然的感觉太抽象了

因为模式较多,所以在没有一定场景的情况下结合简单实例就可能会显得无的放矢,所以可以先看一些设计模式的书籍,针对每个模式一般都有一些实例进行讲解,过程中如果理解上有什么想法,就比较适合在论坛中进行交流了
0 请登录后投票
   发表时间:2007-04-03  
楼主提到了三点

统一:达到一致
概括:提高抽象
分离:降低耦合便于扩展

我觉得降低偶合,也就是解偶是关键,底偶合高内聚,高扩展,高复用是软件设计的目标。
0 请登录后投票
   发表时间:2007-04-04  
jamesby 写道

我觉得降低偶合,也就是解偶是关键,底偶合高内聚,高扩展,高复用是软件设计的目标。

我觉得“底偶合高内聚”应该在设计原则层次,通过原则指导利于达到设计目标——“高扩展,高复用”
0 请登录后投票
   发表时间:2007-04-04  
qinysong 写道
jamesby 写道

我觉得降低偶合,也就是解偶是关键,底偶合高内聚,高扩展,高复用是软件设计的目标。

我觉得“底偶合高内聚”应该在设计原则层次,通过原则指导利于达到设计目标——“高扩展,高复用”
我觉得设计原则应该是

面向接口和抽象编程
优先使用组成而不是继承,也就是HAS A OR IS A 等等,

而遵守设计原则的软件就是高内聚底偶合的设计,也就是高扩展,高复用的设计!

我认为高扩展,高复用是终极目标,但是达到了高内聚底偶合的目标也就达到了高扩展,高复用的目标.

0 请登录后投票
论坛首页 Java企业应用版

跳转论坛:
Global site tag (gtag.js) - Google Analytics