Commit 0f12edf

摒弃了在每个对象中保存所有数据的方式， 通过**共享**多个对象所共有的相同状态， 让你能在有限的内存容量中**载入更多对象**。

1. 仅在程序必须支持**大量对象**且没有足够的内存容量时

**[字符对象](./Assets/DesignPatternsRevisited/FlyweightPattern)**：A-Z每个字符作为一个对象，所有的A，有着相同的属性(内在属性)，例如：width、height等；也有着不同的属性(外在属性)，例如：pointSize

1. 将需要改写为享元的类成员变量拆分为两个部分：

- 内在状态： 包含不变的、 可在许多对象中重复使用的数据的成员变量。

- 外在状态： 包含每个对象各自不同的情景数据的成员变量

2. 保留类中表示内在状态的成员变量， 并将其属性设置为不可修改。 这些变量仅可在构造函数中获得初始数值。

3. 找到所有使用外在状态成员变量的方法， 为在方法中所用的每个成员变量新建一个参数， 并使用该参数代替成员变量。

4. 你可以有选择地创建工厂类来管理享元缓存池， 它负责在新建享元时检查已有的享元。 如果选择使用工厂， 客户端就只能通过工厂来请求享元， 它们需要将享元的内在状态作为参数传递给工厂。

5. 客户端必须存储和计算外在状态 （情景） 的数值， 因为只有这样才能调用享元对象的方法。 为了使用方便， 外在状态和引用享元的成员变量可以移动到单独的情景类中。

**优点**

- 如果程序中有很多相似对象， 那么你将可以节省大量内存。

**缺点**

* 你可能需要牺牲执行速度来换取内存， 因为他人每次调用享元方法时都需要重新计算部分情景数据。

* 代码会变得更加复杂。 团队中的新成员总是会问： “为什么要像这样拆分一个实体的状态？”。

- 你可以使用**享元模式**实现**组合模式***(GOF)*树的共享叶节点以节省内存。

- 享元展示了如何生成大量的小型对象， **外观模式*****(GOF)*则展示了如何用一个对象来代表整个子系统。

- 如果你能将对象的所有共享状态简化为一个享元对象， 那么**享元**就和**单例模式**类似了。 但这两个模式有两个根本性的不同。

1. 只会有一个单例实体， 但是*享元*类可以有多个实体， 各实体的内在状态也可以不同。

2. *单例*对象可以是可变的。 享元对象是不可变的。