对结构型设计模式的理解

在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对象，从而可以在中间提供一些辅助的功能和服务；

评论

17 楼 huangtut 2007-07-03  

学习学习

16 楼 daynight830 2007-04-24  

其实说到底的终极目标应该是：可维护性!

15 楼 qinysong 2007-04-04  

上面这些讨论已经突破了题目话题本身，我把它单独列出去http://www.iteye.com/topic/67885

14 楼 piaochunzhi 2007-04-04  

我不懂 ， 都是用 抽象 在弄 ？？？？

13 楼 qinysong 2007-04-04  

jamesby 写道

是不是也可以这样理解，软件的终极目标，就是复用。
可复用的软件一定是可扩展的，可扩展的一定具有高内聚、底偶合的特点。

而软件设计原则是达到这个目标的通道。设计模式是这个终极目标的表现方式。

我觉得软件设计有两个大的目标：
第一个：可重用性。可重用性通过复用之前的劳动成果提高了生产效率，降低了成本；
第二个：可维护性。可维护性通过延长系统的使用寿命，增值了产品价值；

要想设计达到这两个目标，系统就需要有一些特性
包括可读性、高灵活性、易扩展性、通用性、可移植性，这些特性是一个系统表现出来的，可概括为“白箱特性”：），而系统内部也要有一些属性，如高内聚、低耦合，这些内部属性更侧重内部结构性，概括为“黑箱属性”。

为了使一个系统具有那些优秀的特性，有一些手段，或者称为方法
这些方法/手段包括抽象（提高通用性）、封装（增强内聚性）、分离（降低耦合性）等等

当对这些方法/手段进行细化、分类、概括时，就产生了一些设计原则/准则
比如面向接口编程、优先使用对象组合、SRP单职责准则、OCP准则等等

这些准则/原则在一定场景下的经典表现方式，就产生了设计模式

以上是个人理解，因为这种层次的划分包括大量的理解上、语义上的因素，所以每个人的划分可能会有不同，不过我感觉这样的划分虽然可能因人而异，但是他可以让我们有一个全局观念，所以还是很有意义的，再加上能够相互之间进行切磋，感觉很好

12 楼 jamesby 2007-04-04  

引用

Design Patterns
(设计模式）


Elements of Reuseable Object-Oriented Software

（可复用面向对象软件的基础）


作者:

Erich Gamma

Richard Helm

Ralph Johnson

John Vlissides

可见设计模式是为了复用。

11 楼 jamesby 2007-04-04  

qinysong 写道

jamesby 写道

qinysong 写道

jamesby 写道

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

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

我觉得设计原则应该是

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

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

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

嗯，非常好，这样的讨论非常促进我的认识

我想再引入一个词——属性，一个好的软件，一个最大限度接近优秀目标（高扩展，高复用）的软件本身应该具有一些基本属性，就像高尔基说的“不幸的家庭各有各的不幸，而幸福的家庭都是相似的”，软件也是，不好、劣质的软件各有各的不好之处，而优秀的软件（从设计角度来说）却都具有基本的属性，这些属性中我觉得就可以包括“高内聚、底偶合”。

所以“高内聚、底偶合”这是优秀软件的基本属性，而目标是表达我们最大渴望的主观意愿，一个软件只要高扩展，高复用我们就满足了，在这个满足的前提下我们不在乎是不是高内聚低耦合。但是幸福的家庭都是相似的

比喻的不错。

是不是也可以这样理解，软件的终极目标，就是复用。
可复用的软件一定是可扩展的，可扩展的一定具有高内聚、底偶合的特点。

而软件设计原则是达到这个目标的通道。设计模式是这个终极目标的表现方式。

10 楼 qinysong 2007-04-04  

jamesby 写道

qinysong 写道

jamesby 写道

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

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

我觉得设计原则应该是

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

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

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

嗯，非常好，这样的讨论非常促进我的认识

我想再引入一个词——属性，一个好的软件，一个最大限度接近优秀目标（高扩展，高复用）的软件本身应该具有一些基本属性，就像高尔基说的“不幸的家庭各有各的不幸，而幸福的家庭都是相似的”，软件也是，不好、劣质的软件各有各的不好之处，而优秀的软件（从设计角度来说）却都具有基本的属性，这些属性中我觉得就可以包括“高内聚、底偶合”。

所以“高内聚、底偶合”这是优秀软件的基本属性，而目标是表达我们最大渴望的主观意愿，一个软件只要高扩展，高复用我们就满足了，在这个满足的前提下我们不在乎是不是高内聚低耦合。但是幸福的家庭都是相似的

9 楼 jamesby 2007-04-04  

qinysong 写道

jamesby 写道

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

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

我觉得设计原则应该是

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

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

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

8 楼 qinysong 2007-04-04  

jamesby 写道

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

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

7 楼 jamesby 2007-04-03  

楼主提到了三点

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

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

6 楼 qinysong 2007-04-03  

shenhai 写道

希望能结合一个简单的实例进行讲解，不然的感觉太抽象了

因为模式较多，所以在没有一定场景的情况下结合简单实例就可能会显得无的放矢，所以可以先看一些设计模式的书籍，针对每个模式一般都有一些实例进行讲解，过程中如果理解上有什么想法，就比较适合在论坛中进行交流了

5 楼 shenhai 2007-04-03  

希望能结合一个简单的实例进行讲解，不然的感觉太抽象了

4 楼 qinysong 2007-03-22  

noahgenius 写道

看了对比，我觉得核心思想都一样，连方式也大同小异。

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

但是对于每种模式都有其不同的针对点，都有不同的目的、不同的适用场景和考虑要素，所以这种差异性不能被表面的大同小异所掩盖

3 楼 noahgenius 2006-12-15  

看了对比，我觉得核心思想都一样，连方式也大同小异。

2 楼 qinysong 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模式只代理目标对象，且通常都提供一定的服务。

类结构对比图如下：

1 楼 shaucle 2006-12-14  

似乎上升到哲学了，呵呵