1 意图
运用共享技术有效地支持大量细粒度的对象。
2 动机
有些应用程序得益于在其整个设计过程采用对象技术，但简化的实现代价极大。
例如，大多数文档编辑器的实现都有文本格式化和编辑功能，这些功能在一定程度上是模块化的。面向对象的文档编辑器通常使用对象来表示嵌入的成分，例如表格和图形。尽管用对象来表示文档中的每个字符会极大地提高应用程序的灵活性，但是这些编辑器通常不这么做。字符和嵌入成分可以在绘制和格式化时统一处理，从而在不影响其他功能的情况下能对应用程序进行扩展，支持新的字符集。应用程序的对象结构可以模拟文档的物理结构。下图显示了一个文档编辑器怎样使用对象来表示字符：
但这种设计的缺点在于代价太大。即使是一个中等大小的文档也可能要求成百上千的字符对象，这会耗费大量内存，产生难以接受的运行开销。所以通常并不是对每个字符都用一个对象来表示的。Flyweight模式描述了如何共享对象，使得可以细粒度地使用它们而无需高昂的代价。
Flyweight是一个共享对象，它可以同时在多个场景中使用，并且在每个场景Flyweight都可以作为一个独立的对象——这一点与非共享对象的实例没有区别。Flyweight不能对它所运行的场景做出任何假设，这里的关键概念是内部状态和外部状态之间的区别。内部状态存储于Flyweight中，它包含了独立于Flyweight场景的信息，这些信息使得Flyweight可以被共享。而外部状态取决于 Flyweight场景，并根据场景而变化，因此不可共享。用户对象负责在必要的时候将外部状态传递给Flyweight。
Flyweight模式对那些通常因为数量太大而难以对象来表示的概念或实体进行建模。例如，文档编辑器可以为字母表中的每一个字母创建一个Flyweight。每个Flyweight存储一个字符代码，但它在文档中的位置和排版风格可以在字符出现由正文排版算法和使用的格式化命令决定。字符代码是内部状态，而其它的信息则是外部状态。
逻辑上，文档中的给定字符每次出现都有一个对象与其对应，如下图所示：
然而，物理上每个字符共享一个Flyweight对象，而这个对象出现在文档结构中的不同地方。一个特定字符对象的每次出现都指向同一个实例，这个实例位于Flyweiht对象的共享池中。
这些对象的类结构如下图所示，Glyph是图形对象的抽象类，其中有些对象可能是Flyweight。基于外部状态的那些操作将外部状态作为参量传递给它们。例如，Draw和Intersects在执行之前，必须知道glyph所在的场景，如下图所示：
表示字母“”a“”的flyweight只存储相应的字符代码，它不需要存储字符的位置或字体。用户提供与场景相关的信息，根据此信息flyweight绘出它自己。例如，Row glyph知道它的子女应该在哪儿绘制自己才能保证它们横向排列。因此Row glyph可以在绘制请求中向每一个子女传递它的位置。
由于不同的字符对象数远小于文档中的字符数，因此，对象的总数远小于一个初次执行的程序所使用的对象数目。对于一个所有字符都使用同样的字体和颜色的文档而言，不管这个文档多长，需要分配100个左右的字符对象，由于大多数文档使用的字体颜色组合不过10种，实际应用中这一数目不会明显增加。因此，对单个字符进行抽象的具有实际意义的。
3 适用性
Flyweight模式的有效性很大程度上取决于如何使用它以及在何处使用它。当以下情况都成立时使用Flyweight模式：
- 1 一个应用程序使用了大量的对象；
- 2 完全由于使用大量的对象，造成了很大的存储开销；
- 3 对象的大多数状态都可以变成外部状态；
- 4 如果删除对象的外部状态，那么可以相对较少的共享对象取代很多组对象；
- 5 应用程序不依赖对象标识，由于Flyweight对象可以被共享，对于概念上明显有别的对象，标识测试将返回真值。
4 结构
下面的对象图说明了如何共享flyweight:
5 参与者
- Flyweight(Glyph)
——描述一个接口，通过这个接口flyweight可以接受并作用于外部状态； - ConcreteFlyweight（Character）
——实现Flyweight接口，并为内部状态（如果有的话）增加存储空间。ConcreteFlyweight对象必须是可共享的。它所存储的状态必须是内部的，它必须独立ConcreteFlyweight对象的场景。 - UnsharedConcreteFlyweight(Row, Column)
——并非所有的Flyweight子类都需要被共享。Flyweight接口使共享成为可能，但它并不强制共享。在Flyweight对象结构的某些层次，UnsharedConcreteFlyweight对象通常将ConcreteFlyweight对象作为子节点（Row, Column就是这样）。 - FlyweightFactory
——创建并管理flyweight对象；
——确保合理地共享flyweight。当用户请求一个flyweight时，FlyweightFactory对象提供一个已创建的实例或者创建一个（如果不存在的话） - Client
——维持一个对Flyweight的引用
——计算或存储一个（多个）Flyweight的外部状态。
6 协作
- Flyweight执行时所需的状态必定是内部的或外部的。内部状态存储于ConcreteFlyweight对象之中：而外部对象则由Client对象存储或计算。
- 用户不应直接对ConcreteFlyweight类进行实例化，而只能从FlyweightFactory对象得到ConcreteFlyweight对象，这可以保证对它们适当地进行共享。
7 效果
使用Flyweight模式时，传输、查找和 /或计算外部状态都会产生运行时的开销，尤其当Flyweight原先被存储为内部状态时。然而，空间上的节省抵消了这些开销。共享的Flyweight越多，空间节省也就越大。存储节约由以下几个因素决定：
- 因为共享，实例总数减少的数目；
- 对象内部状态的平均数目；
- 外部状态是计算的还是存储的
8 实现
在实现Flyweight模式时，注意以下几点：
- 1 删除外部状态：该模式的可用性在很大程度上取决于是否容易识别外部状态并将它从共享对象中删除；
- 2 管理共享对象： 因为对象是共享的，用户不能直接对它进行实例化，因此 Flyweight-Factory可以帮助用户查找某个特定的 Flyweight对象。
