Fly Weight 享元模式

动机

有些程序需要大量带有内部共享状态的对象实例。作为例子，我们设想一个战争游戏，里边存在很多 soldier 对象，soldier 对象维持着士兵行为的图形化表示，如移动和射击，另外还有士兵的生命值和在阵地中的位置。虽然创建大量的 soldier 对象是必要的，但这会消耗大量的内存。

目的

此模式的目的是利用状态共享来支撑需要大量实例对象的场景，这些对象有部分相同的内部状态，另外一些则不一致。

实现

以下是享元模式的 UML 类图 (Extrinsic State: 外部状态， Intrinsic State: 内部状态 )

• Flyweight 声明一个接口，通过这个接口享元接收并根据外部状态采取行动
• ConcreteFlyweight 实现 Flyweight 接口并保存内部状态。ConcreteFlyweight 对象必须是可共享的。享元实例对象必须在保持内部状态的同时能够对外部状态进行操作。在战争游戏的例子里，图形表示是内部状态，位置和生命值是外部状态。士兵移动过程中，动作行为操作位置这个外部状态从而产生新的位置。
• FlyweightFactory 此工厂新建和管理享元对象。此外，享元工厂确保享元对象的共享。工厂维持着一个包含各类享元的对象池。如果一类对象已经创建过了，则直接从对象池中返回。如果是新的对象，则将其添加入对象池中。
  在战争游戏的例子中，士兵的享元工厂创建两种类型的享元：士兵享元和上校享元。当客户端请求获取一个士兵时，享元工厂检查对象池中是否已有士兵对象，有的话直接返回，没有的话就新建一个士兵对象，塞入池中并返回给客户端；下一次客户端再请求士兵时，将直接返回先前创建的士兵对象，不会再创建新的。
• Client 客户端维持享元对象的引用，此外还计算和维持外部状态

如果客户端需要一个享元对象，它会访问工厂来获取。工厂检查享元对象池，看请求的对象类型是否在池中，如果存在，则返回该对象的引用；如果不存在，工厂会创建该类对象，将其加入对象池中，并将其引用返回给客户端。享元维持内部状态（我们创建享元来在大量对象中共享的状态）并提供方法来操作外部状态（这些状态在各个对象中各不相同）

适用范围和例子

享元模式适用于适用存在大量对象的程序，并且这些对象的一部分内部状态可以共享，另外一部分状态则有所不同。

示例 - 战争游戏

游戏实例化5个 SoldierClient， 每个 client 负责维护自己的内部状态，这些状态对于士兵享元来说是外部的。尽管实例化了5个 client， 但是仅使用了一个 Soldier 享元对象。

源码：design-patterns/flyweigh/Soldier

再一个例子 - 文本编辑器

面向对象的文本编辑器需要创建字符对象 Character 来表示文件中的每个字符。每个字符对象 Character 维护着它是什么字符，是什么字体，字符的大小以及它在文件中的位置等信息。一个文件通常由及其庞大的字符对象集组成，也就会占用非常多的内存。注意，一般来说字符的数量（数字，字母和其他特殊字符）是已知并且固定的，而且能应用于每个字符上的字体也是已知的；所以，通过创建管理字符类型信息（字母，数字等）和字体信息的 Letter 字母享元，然后再创建只维护字符在文件中位置的Letter Client 字母消费者对象， 我们就大大降低了编辑器的内存需求。
源码： design-patterns/flyweigh/character

总结

享元模式通过在消费端共享享元对象来节省内存消耗。所能节省的内存量取决于享元种类的个数（如上面例子中讨论的士兵分类和上校分类）。

相关模式

工厂 和 单例模式 - 享元模式一般会使用一个生产享元的工厂，并将单例应用于这个工厂，这样每个种类的享元只会返回一个实例。
状态 和 策略模式 - 状态和策略模式的对象也经常实现为享元模式

JDK中的应用

java.lang.Integer#valueOf(int) (also on Boolean, Byte, Character, Short, Long and BigDecimal)
Long 的内部类 LongCache 即为享元对象池，其中缓存了 [-128, 127] 范围的长整型包装类实例； 如果通过 Long.valueOf(n) 获取实例，在范围内的就直接从 LongCache 中返回； Long 在其内部保存基本类型 long (注意是小写)的值，并提供 parseLong, intValue, floatValue, longValue 等方法返回基本类型值的外部状态，正是符合享元模式的使用场景。