锁定老帖子 主题:对结构型设计模式的理解
精华帖 (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对象,从而可以在中间提供一些辅助的功能和服务;
声明:ITeye文章版权属于作者,受法律保护。没有作者书面许可不得转载。
推荐链接
|
|
返回顶楼 | |
发表时间:2006-12-14
似乎上升到哲学了,呵呵
|
|
返回顶楼 | |
发表时间: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模式只代理目标对象,且通常都提供一定的服务。 类结构对比图如下: |
|
返回顶楼 | |
发表时间:2006-12-15
看了对比,我觉得核心思想都一样,连方式也大同小异。
|
|
返回顶楼 | |
发表时间:2007-03-22
noahgenius 写道 看了对比,我觉得核心思想都一样,连方式也大同小异。
其实我们谈论的设计模式(源GOF)的最终目标都是创建易于复用、易于维护的面向对象设计,且这些模式大多也只使用有限的几种技术,如类继承和对象组合,所以粗看起来可能都差不多,特别是结构和联结方式 但是对于每种模式都有其不同的针对点,都有不同的目的、不同的适用场景和考虑要素,所以这种差异性不能被表面的大同小异所掩盖 |
|
返回顶楼 | |
发表时间:2007-04-03
希望能结合一个简单的实例进行讲解,不然的感觉太抽象了
|
|
返回顶楼 | |
发表时间:2007-04-03
shenhai 写道 希望能结合一个简单的实例进行讲解,不然的感觉太抽象了
因为模式较多,所以在没有一定场景的情况下结合简单实例就可能会显得无的放矢,所以可以先看一些设计模式的书籍,针对每个模式一般都有一些实例进行讲解,过程中如果理解上有什么想法,就比较适合在论坛中进行交流了 |
|
返回顶楼 | |
发表时间:2007-04-03
楼主提到了三点
统一:达到一致 概括:提高抽象 分离:降低耦合便于扩展 我觉得降低偶合,也就是解偶是关键,底偶合高内聚,高扩展,高复用是软件设计的目标。 |
|
返回顶楼 | |
发表时间:2007-04-04
jamesby 写道 我觉得降低偶合,也就是解偶是关键,底偶合高内聚,高扩展,高复用是软件设计的目标。 我觉得“底偶合高内聚”应该在设计原则层次,通过原则指导利于达到设计目标——“高扩展,高复用” |
|
返回顶楼 | |
发表时间:2007-04-04
qinysong 写道 jamesby 写道 我觉得降低偶合,也就是解偶是关键,底偶合高内聚,高扩展,高复用是软件设计的目标。 我觉得“底偶合高内聚”应该在设计原则层次,通过原则指导利于达到设计目标——“高扩展,高复用” 面向接口和抽象编程 优先使用组成而不是继承,也就是HAS A OR IS A 等等, 而遵守设计原则的软件就是高内聚底偶合的设计,也就是高扩展,高复用的设计! 我认为高扩展,高复用是终极目标,但是达到了高内聚底偶合的目标也就达到了高扩展,高复用的目标. |
|
返回顶楼 | |