设计模式之结构型模式

《设计模式：可复用面向对象软件的基础》第四章 结构型模式

一、ADAPTER（适配器）

1.意图

将一个类的接口转换成客户希望的另一个接口。Adapter模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。

2.适用情况

• 你想使用一个已经存在的类，而它的接口不符合你的需求。
• 你想创建一个可以复用的类，该类可以与其他不相关的类或不可预见的类（即那些接口可能不一定兼容的类）协同工作。
• （仅适用于对象Adapter）你想使用一些已经存在的子类，但是不可能对每一个都进行子类化以匹配它们的接口。对象适配器可以适配它的父类接口。

3.结构

4.相关模式

模式Bridge的结构与对象适配器类似，但是Bridge模式的出发点不同：Bridge目的是将接口部分和实现部分分离，从而对它们可以较为容易也相对独立的加以改变。而Adapter则意味着改变一个已有对象的接口。

Decorator模式增强了其他对象的功能而同时又不改变它的接口。因此decorator对应用程序的透明性比适配器要好。结果是decorator支持递归组合，而纯粹使用适配器是不可能实现这一点的。、

模式Proxy在不改变它的接口的条件下，为另一个对象定义了一个代理。

二、BRIDGE（桥接）

1.意图

将抽象部分与它的实现部分分离，使它们都可以独立的地变化。

2.适用情况

• 你不希望在抽象和它的实现部分之间有一个固定的绑定关系。例如这种情况可能是因为，在程序运行时刻实现部分可以被选择或者切换。
• 类的抽象以及它的实现都应该可以通过生成子类的方法加以扩充。这时Bridge模式使你可以对不同的抽象接口和实现部分进行组合，并分别对它们进行扩充。
• 对一个抽象的实现部分的修改对应对客户不产生影响，即客户的代码不必重新变异。
• （C++）你想对客户完全隐藏抽象的实现部分。在C++中，类的便是在类接口中是可见的。
• 你必须将对象分解成两个部分。
• 你想在对个对象间共享实现（可能使用引用计数），但同时要求客户并不知道这一点。

3.结构

4.相关模式

Abstract Factory模式可以用来创建和配置一个特定的Bridge模式。

Adapter模式用来帮助无关的类协同工作，它通常在系统设计完成后才会被使用。然而，Bridge模式则是在系统开始时就被使用，它使得抽象接口和实现部分可以独立进行改变。

三、COMPOSITE（组合）

1.意图

将对象组合成树形结构表示“部分-整体”的层次结构。Composite使得用户对单个对象和组合对象的使用具有一致性。

2.适用情况

• 你想表示对象的部分-整体层次结构。
• 你希望用户忽略组合对象与单个对象的不同，用户将统一地组合结构中的所有对象。

3.结构

4.相关模式

通常部件-父部件连接用于Responsibility of Chain模式。

Decorator模式经常与Composite模式一起使用。当装饰与组合一起使用时，它们通常有一个公共的父类。因此装饰必须支持Add、Remove和GetChild的Comoonent接口。

Flyweight让你共享组件，但不再能引用他们的父部件。

Iteror可用来遍历Composite。

Visitor将本来应该分布在Composite和Leaf类中的操作和行为局部化。

四、DECORATOR（装饰）

1.意图

动态地给一个对象添加一些额外的职责。就增加功能来说，Decorator模式相比生成子类更为灵活。

2.适用情况

• 在不影响其他对象的情况下，以动态、透明的方式给对象添加职责。
• 处理那些可以撤销的职责。
• 当不能采用生成子类的方法进行扩充时。一种情况是，可能有大量独立的扩展，为支持每一种组合将产生大量的子类，使得子类数目呈爆炸性增长。另一种情况是因为类定义被隐藏，或类定义不能用于生成子类。

3.结构

4.相关模式

Adapter模式：Decorator模式不同于Adapter模式，因为装饰者仅改变对象的职责而不改变它的接口；而适配器将对象一个全新的接口。

Composite模式：可以将装饰视为一个退化的、仅有一个组件的组合。然而，装饰仅给对象添加一些额外的职责——它的目的不在于对象聚集。

Strategy模式：用一个装饰你可以改变对象的外表；而Strategy模式使得你可以改变对象的内核，这是改变对象的两种途径。

五、FACADE（外观）

1.意图

为子系统中的一组接口提供一个一致的界面，Facade模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。

2.适用情况

• 当你要为一个复杂子系统提供一个简单接口时。
• 客户程序与抽象类的实现部分之间存在很大的依赖行。
• 当你需要构建一个层次结构的子系统时，使用facade模式定义子系统中的每层的入口点。如果子系统之间是相互依赖的，你可以让它们仅通过facade进行通讯，从而简化他们之间的依赖关系。

3.结构

4.相关模式

Abstract Factory模式可以与Facade模式一起使用以提供一个接口，这一接口用来一一种子系统独立的方式创建子系统对象。Abstract Factory也可以代替Facade模式隐藏那些与平台相关的类。

Mediator 模式与Facade模式的相之处是，它抽象了一些已有的类的功能。然而Mediator的目的是对同事之间的任意通讯进行抽象，通常集中不属于任何单个对 象的功能。Mediator的同事对象知道中介者并与它通信，而不是直接与其他同类对象通信。相对而言，Facade模式仅对子系统的接口进行抽象，从而 使它们更容易使用；它并不定义新功能，子系统也不知道facade的存在。

通常来讲，仅需要一个Facade对象，因此Facade对象通常属于Singleton模式。

六、FLYWEIGHT（享元）

1.意图

运用共享技术有效地支持大量细粒度的对象。

2.适用情况

• 一个应用程序使用了大量的对象。
• 完全由于使用大量的对象，造成很大的存储开销。
• 对象的大多数状态都可变为外部状态。
• 如果删除对象的外部状态，那么可以用相对较小的共享对象取代很多组对象。
• 应用程序不依赖于对象标识。由于Flyweight对象可以被共享，对于概念上明显有别的对象，标识测试就爱那个返回真值。

3.结构

4.相关模式

Flyweight模式通常和Composite模式结合起来，用共享结点的有向无环图实现一个逻辑上的层次结构。

通常，最好用Flyweight实现State和Strategy对象。

七、PROXY（代理）

1.意图

为其他对象提供一种代理以控制这个对象的访问。

2.适用情况

在需要用比较通用和复杂的对象指针代替简单的指针的时候，使用Proxy模式。

3.结构

4.相关模式

Adapter：适配器Adapter为它所适配的对象提供了一个不同的接口。相反，代理提供了与它的实体相同的接口哦。然而，用于访问保护的代理可能会拒绝执行实体会执行的操作，因此，它的接口实际上可能只是实体接口的一个子集。

Decorator：尽管decorator的实现部分与代理相似，但decorator的目的不一样。Decorator为对象添加一个或多个功能，而代理则控制对象的访问。

代 理的实现与decorator的实现类似，但是在相似的程度上有所差别。Protection Proxy的实现可能与decorator的实现差不多。另一方面，Remote Proxy不包含对实体的直接引用，而只是一个间接引用。Virtual Proxy开始的时候使用一个间接引用，但最终将获取并使用一个直接引用。

八、结构型模式总结

1.Adapter与Bridge

Adapter模式和Bridge模式具有一些共同的特征。它们都给另一对象提供了一定程度上的间接性，因而有利于系统的灵活性。它们都涉及到从自身意外的一个接口向这个对象转发请求。

这 些模式的不同之处主要在于它们各自的用途。Adapter模式主要是为了解决来那个已有接口之间不匹配的问题。它不考虑这些接口是怎样实现的，也不考虑它 们各自可能会如何演化。这种方式不需要对两个独立设计的类中的任一个进行重新设计，就能使它们协同工作。另一方面，Bridge模式则对抽象接口与它的 （可能是多个）实现部分进行桥接。虽然这一模式允许你修改实现它的的类，它仍然为用户提供了一个稳定的接口。Bridge模式也会在系统演化时适应新的实 现。

2.Composite、Decorator与Proxy

Composite模式和Decorator模式具有类似的结 构图，这说明它们都基于递归组合来组织可变数目的对象。这一共同点可能会使你认为，decroator对象是一个退化的composite，但这一观点没 有领会Decorator模式的要点。相似点仅止于递归组合，同样，这是因为这两个模式的目的不同。

Decorator旨在使你能够不需要 生成子类即可给对象添加职责。这就避免了静态实现所有功能组合，从而导致子类急剧增加。Composite则有不同的目的，它旨在构造类，使对个相关的对 象能够以统一的方式处理，而多重对象可以被当作一个对象来处理。它重点不在于修饰，而在于表示。

尽管它们的目的截然不同，但却具有互补性。 因此Composite和Decorator模式通常协同使用。在使用这两种模式进行设计时，我们无需定义新的类，仅需将一些对象插接在一起即可构建应 用。这时系统中将会有一个抽象类，它有一些composite子类和decorator子类，还有一些实现系统的基本构建模块。此 时，composites和decorator将拥有共同的接口。从Decorator模式的角度看，composite是一个 ConcreteComponent。而从composite模式的角度看，decorator则是一个Leaf。当然，他们不一定要同时使用，正如我们 所见，它们的目的有很大的差别。

另一种与Decorator模式结构相似的模式是Proxy。这两种模式都描述了怎样为对象提供一定程度上的间接引用，proxy和decorator对象的实现部分都保留了指向另一个对象的指针，它们向这个对象发送请求。然而同样，它们具有不同的设计目的。

像 Decorator模式一样，Proxy模式构成一个对象并为用户提供一致的接口。但与Decorator模式不同的是，Proxy模式不能动态地添加或 分离性质，它也不是为递归组合而设计的。它的目的是，当直接访问一个实体方便或不符合需求时，为这个实体提供一个i阿替代者，例如，实体在远程设备上，访 问受到限制或者实体是持久存储的。

在Proxy模式中，实体定义了关键功能，而Proxy功能提供（或拒绝）对它的访问。在 Decorator模式中，组件仅提供了部分功能，而一个或多个Decorator负责完成其他功能。Decorator模式适用于编译时不能（至少不方 便）确定对象的全部功能的情况。这种开放性使递归组合成为Decorator模式中一个必不可少的部分。而在Proxy模式中则不是这样，因为Proxy 模式强调一种关系（Proxy和它的实体之间的关系），这种关系可以静态的表达。