《设计模式》— 结构型模式 — 享元模式

一、意图

有些应用程序得益于在其整个设计过程中采用对象技术，但简单化的实现代价极大。

例如，大多数文档编辑器的实现都有文本格式化和编辑功能，这些功能在一定程度上是模块化的。面向对象的文档编辑器通常使用对象来表示嵌入的成分，例如表格和图形。尽管用对象来表示文档中的每个字符会极大地提高应用程序的灵活性，但是这些编辑器通常并不这样做。字符和嵌入成分可以在绘制和格式化时统一处理，从而在不影响其他功能的情况下对应用程序进行扩展，支持新的字符集。应用程序的对象结构可以模拟文档的物理结构。其结构如图：

但这种设计的缺点在于代价太大。即使是一个中等大小的文档也可能要求成百上千的字符对象，这会耗费大量内存，产生难以接受的运行开销。所以通常并不是对每个字符都用一个对象来表示。Flyweight 模式描述了如何共享对象，使得可以细粒度地使用它们而不需要高昂的代价。

flyweight 是一个共享对象，它可以同时在多个场景使用，并且在每个场景中 flyweight 都可以作为一个独立的对象 —— 这一点与非共享对象的实例没有区别。flyweight 不能对它所运行的场景做出任何假设，这里的关键概念是内部状态和外部状态之间的区别。内部状态存储于 flyweight 中，它包含了独立于 flyweight 场景的信息，这些信息使得 flyweight 可以被共享。而外部状态取决于 flyweight 场景，并根据场景而变化，因此不可共享。用户对象负责在必要的时候将外部状态传递给 flyweight。

Flyweight 模式对那些通常由于数量太大而难以用对象来表示的概念或实体进行建模。例如，文档编辑器可以为字母表中的每一个字母创建一个 flyweight。每个 flyweight 存储一个字符代码，但它在文档中的位置和排版风格可以在字符出现时由文本排版算法和使用的格式化命令决定。字符代码是内部状态，而其他的信息则是外部状态。

逻辑上，文档中的给定字符每次出现时都有一个对象与其对应，如下图所示：

然而，物理上每个字符共享一个 flyweight 对象，而这个对象出现在文档结构中的不同地方。一个特定字符对象的每次出现都指向同一个实例，这个实例位于 flyweight 的共享池中。

这些对象的类结构如下所示。Glyph 是图形对象的抽象类，其中有些对象可能是 flyweight。基于外部状态的那些操作将外部状态作为参量传递给它们。例如，Draw 和 Intersects 在执行之前必须知道 glyph 所在的场景，如下图所示。

表示字母 a 的 flyweight 只存储相应的字符代码，它不需要存储字符的位置或字体。用户提供与场景相关的信息，根据此信息 flyweight 绘出它自己。例如，Row glyph 知道它的子女应该在哪里绘制自己才能保证它们是横向排列的。因此 Row glyph 可以在绘制请求中向每一个子女传递它的位置。

由于不同的字符对象数远小于文档中的字符数（中文也适用），因此，对象的总数远小于一个初次执行的程序所使用的对象数目。对于一个所有字符都是用同样的字体和颜色的文档而言，不管这个文档有多长，需要分配100个左右的字符对象。由于大多数文档使用的字体颜色组合不超过10种，实际应用中这一数目不会明显增加。因此，对单个字符进行对象抽象是有实际意义的。

二、适用性

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

三、结构

四、参与者

1、FlyWeight

描述一个接口，通过这个接口 flyWeight 可以接受并作用于外部状态。

2、ConcreteFlyWeight

实现 FlyWeight 接口，并为内部状态（如果有的话）增加存储空间。ConcreteFlyWeight 对象必须是可共享的。它所存储的状态必须是内部的，即它必须独立于 ConcreteFlyWeight 的场景。

3、UnsharedConcreteFlyWeight

并非所有的 FlyWeight 子类都需要被共享。FlyWeight 接口使共享成为可能，但它并不强制共享。在 flyWeight 对象结构的某些层次，UnsharedConcreteFlyWeight 对象通常将 ConcreteFlyWeight 对象作为子结点（如 Row 和 Column）。

4、FlyWeightFactory

• 创建并管理 flyWeight 对象。
• 确保合理地共享 flyWeight。当用户请求一个 flyWeight 时，FlyWeightFactory 对象提供一个已创建的实例或者创建一个。

5、Client

• 维持一个对 flyWeight 的引用。
• 计算或存储一个（多个） flyWeight 的外部状态。

五、协作

用户不应对 ConcreteFlyWeight 类进行实例化，而只能从 FlyWeightFactory 对象得到 ConcreteFlyWeight 对象，这可以保证对它们适当地进行共享。

六、效果

使用 FlyWeight 模式时，传输、查找和计算外部状态都会产生运行时开销，尤其当 flyWeight 原先被存储为内部状态时。然而， 空间上的节省抵消了这些开销。共享的 flyWeight 越多，空间节省也就越大。

存储节约由以下几个因素决定：

• 由于共享带来的实例总数减少的数目
• 对象内部状态的平均数目
• 外部状态是计算的还是存储的

FlyWeight 模式经常和 Composite 模式结合起来表示一个层次式结构，这一层次式结构是一个共享叶节点的图。共享的结果是，flyWeight 的叶节点不能存储指向父节点的指针，而父节点的指针将传给 flyWeight 作为它的外部状态的一部分。这将对该层次结构中对象之间相互通信的方式产生很大的影响。

七、实现

1、删除外部状态

该模式的可用性在很大程度上取决于是否容易识别外部状态并将它从共享对象中删除。如果不同种类的外部状态和共享前对象的数目相同的话，删除外部状态不会降低存储消耗。理想的状况是，外部状态可以有一个单独的对象结构计算得到，且该结构存储的要求非常小。

例如，在文档编辑器中，可以用一个单独的结构存储排版布局信息，而不是存储每一个字符对象的字体和类型信息，布局图保持了带有相同排版信息的字符的运行轨迹。当某字符绘制自己的时候，作为绘图遍历的副作用它接收排版信息。因为通常文档时用的字体和类型数量有限，所以将该信息作为外部信息来存储要比内部存储高效的多。

2、管理共享对象

因为对象是共享的，用户不能直接对它进行实例化，所以 FlyWeightFactory 可以帮助用户查找某个特定的 flyWeight 对象。FlyWeightFactory 对象经常使用关联存储帮助用户查找感兴趣的 flyWeight 对象。

共享还意味着某种形式的引用计数和垃圾回收。

八、应用

在 Java 的 Spring 框架中，使用 IOC 容器进行类实例的管理。使用单例定义的对象可以认为是共享对象，使用原型定义的对象一般为非共享对象。这里的外部状态是一个更宽泛的概念，可以认为是获取该实例的运行程序上下文。