设计模式之结构模式集合

结构模式描述如何将类或者对象结合在一起形成更大的结构。再来回顾一下各个结构模式的意图和结构。

1. 组合模式的基本介绍

意图

适配器模式是一种类对象结构性模式，其意图是将一个类的接口转换成客户希望的另外一个接口。Adapter模式使得原本由于接口不兼容而不能再一起工作的那些类可以一起工作。

结构

适配器模式包括2种形式，
  1、类适配
  2、对象适配

• 类适配器模式

• 对象适配器模式

主要包含如下几个部分：

• Target
  • 定义Client使用的与特定领域相关的接口。
• Adaptee
  • 定义一个已经存在的接口，这个接口需要适配。
• Adapter
  • 对Adaptee的接口和与Target接口进行适配。

详见《适配器模式浅析》

2. 组合模式的基本介绍

意图

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

结构

组合模式的基本结构如下：

这里涉及到的参与者有如下几种：

• Component角色
  • 这是一抽象角色，它给参加组合的对象规定一个接口，规范共有的接口及默认行为。
• Leaf角色
  • 在组合中表示叶节点对象，叶子节点没有子节点。
• Composite角色
  • 代表参加组合的有子对象的对象，定义出这样的对象的行为。
• Client角色
  • 通过Component接口操纵组件的对象

参与者如何协作？

用户使用Component类接口与组合结构中的对象进行交互。如果接收者是一个叶子节点，则直接处理请求。如果接收者是Composite，它通常将请求发送给它的子部件，在转发请求之前与/或之后可能执行一些辅助操作。

详见《组合模式浅析》

3. 装饰模式的基本介绍

意图

动态地给一个对象添加额外的职责。

结构

装饰者模式的基本结构如下：

• Component

定义一个对象接口，可以给这些对象动态地添加职责。

• ConcreteComponent

定义一个对象，可以给这个对象添加一些职责。

• Decorator

装饰角色，持有一个Component对象的实例，并定义一个与Componnet接口一致的接口。

• ConcreteDecorator

具体装饰角色，负责给组件添加职责。

详见《装饰者模式浅析》

4. 代理模式的基本介绍

意图

为其它对象提供一种代理以控制对这个对象的访问。我们可以使用代理模式在目标对象实现的基础上，以增加额外的功能操作或者逻辑，即可扩展目标对象的功能。

结构

代理模式的基本结构如下：

• Subject

定义和RealSubject和Proxy的共用接口，这样就在任何使用RealSubject的地方都可以使用Proxy。

• RealSubject

定义Proxy所代表的实体。

• Proxy

保存一个引用使得代理可以访问实体。

详见《聊聊代理那些事》

5. 享元模式的基本介绍

意图

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

结构

享元模式的基本结构如下：

这里涉及到的参与者有如下几种：

• 抽象享元角色（Flyweight）
  • 此角色是所有的具体享元的超超类，为这些类规定出需要实现的公共接口。那些需要外部状态的操作可以通过方法的参数传入
• 具体享元角色（ConcreteFlyweight）
  • 实现抽象享元角色所规定的接口。如果有内部状态的话，必须负责为内部状态提供存储空间。享元对象的内部状态必须与对象所处的周围环境无关，从而使得享元对象可以在系统内部共享。
• 非共享享元角色（UnsharedConcreteFlyweight）
  • 并非所有Flyweight的子类都需要被共享。Flyweight接口使共享成为可能，但它并不是强制共享。在Flyweight对象结构的某些层次，UnsharedFlyweight对象通常将ConcreteFlyweight对象作为子节点。
• 享元工厂（FlyweightFactory）
  • 创建并管理享元对象。
  • 确保合理地共享Flyweight。当用户请求一个Flyweight的时候，享元工厂对象提供一个已创建的实例或者创建一个（如果不存在的话）
• 客户端（Client）
  • 维持一个对Flyweight对象的引用。
  • 计算或者存储一个（多个）Flyweight的外部状态。

详见《享元模式浅析》

6. 门面模式的基本介绍

意图

门面模式是一种对象结构型模式，其意图是为子系统中的一组接口提供一个一致的界面，Facade模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。

结构

门面模式的基本结构如下：

• Facade
  • 知道哪些子系统类负责处理请求
  • 将客户的请求代理给适当的子系统对象
• Subsystem class
  • 实现子系统的功能
  • 处理由Facade对象指派的任务
  • 没有facade的任何相关信息；即没有指向facade的指针

详见《门面模式浅析》

7. 桥接模式的基本介绍

意图

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

结构

桥接模式的基本结构如下：

这里涉及到的参与者有如下几种：

• Abstract（抽象化）角色
  • 抽象化给出的定义，并保存一个对实现化对象的引用。
• RefinedAbstarct（修正抽象化）角色
  • 扩展抽象化角色，改变和修正父类对抽象化的定义。
• Implementor（实现化）角色
  • 这个角色给出实现化角色的接口，但不给出具体的实现。必须指出的是，这个接口不一定和抽象化角色的接口定义相同，实际上，这两个接口可以非常不一样。实现化角色应用只给出底层操作，而抽象化角色应当只给出基于底层操作的更高一层的操作。
• ConcreteImplementor（具体实现化）角色
  • 这个角色给出实现化角色接口的具体实现。

详见《桥接模式浅析》

不知不觉，已经将结构模式都写了一遍了，有兴趣的朋友可以一起研读、交流。