设计模式 ☞ 结构型模式之享元模式
1.1 简介
1.1.1 概述
享元(Flyweight)模式的定义：运用共享技术来有效地支持大量细粒度对象的复用。它通过共享已经存在的对象来大幅度减少需要创建的对象数量、避免大量相似类的开销，从而提高系统资源的利用率。在面向对象程序设计过程中，有时会面临要创建大量相同或相似对象实例的问题。创建那么多的对象将会耗费很多的系统资源，它是系统性能提高的一个瓶颈。 例如，围棋和五子棋中的黑白棋子，图像中的坐标点或颜色，局域网中的路由器、交换机和集线器，教室里的桌子和凳子等。这些对象有很多相似的地方，如果能把它们相同的部分提取出来共享，则能节省大量的系统资源，这就是享元模式的产生背景。
1.1.2 优缺点
优点： ① 相同对象只要保存一份，这降低了系统中对象的数量，从而降低了系统中细粒度对象给内存带来的压力。
缺点： ① 为了使对象可以共享，需要将一些不能共享的状态外部化，这将增加程序的复杂性。 ② 读取享元模式的外部状态会使得运行时间稍微变长。
1.2 案例
享元模式结构图如上图所示，举例解释上图，咱们开发了一款射击游戏，每个粒(一颗子弹、一枚导弹或一块弹片)都由包含完整数据的独立对象来表示。尽管该游戏在你的电脑上完美运行，但是你朋友却无法长时间进行游戏：游戏总是会在他的电脑上运行几分钟后崩溃。在研究了几个小时的调试消息记录后，发现导致游戏崩溃的原因是内存容量不足。朋友的设备性能远比不上你的电脑，因此游戏运行在他的电脑上时很快就会出现问题。
仔细观察 粒子类，可能 颜色 和 精灵图 这两个成员变量所消耗的内存要比其他变量多得多。而且，对于所有的粒子来说，这两个成员变量所存储的数据几乎完全一样。每个粒子的另一些状态(坐标、移动矢量和速度)则是不同的。因为这些成员变量的数值会不断变化。对象的常量数据通常被称为内在状态，其位于对象中，其他对象只能读取但不能修改其数值。而对象的其他状态常常能被其他对象 “从外部” 改变，因此被称为外在状态。 享元模式建议不在对象中存储外在状态，而是将其传递给依赖于它的一个特殊方法。程序只在对象中保存内在状态，以方便在不同情景下重用。这些对象的区别仅在于其内在状态(与外在状态相比，内在状态的变体要少很多)，因此你所需的对象数量会大大削减。假如能从粒子类中抽出外在状态，那么我们只需三个不同的对象(子弹、导弹和弹片)就能表示游戏中的所有粒子。我们将这样一个仅存储内在状态的对象称为享元。
那么外在状态会被移动到什么地方呢？总得有类来存储它们，在大部分情况中，它们会被移动到容器对象中，也就是我们应用享元模式前的聚合对象中。在我们的例子中，容器对象就是主要的 游戏对象，其会将所有粒子存储在名为 粒子 的成员变量中。为了能将外在状态移动到这个类中，你需要创建多个数组成员变量来存储每个粒子的坐标、方向矢量和速度。除此之外，还需要另一个数组来存储指向代表粒子的特定享元的引用。这些数组必须保持同步，这样才能够使用同一索引来获取关于某个粒子的所有数据。 更优雅的解决方案是创建独立的情景类来存储外在状态和对享元对象的引用。在该方法中，容器类只需包含一个数组。现在，消耗内存最多的成员变量已经被移动到很少的几个享元对象中了。一个享元大对象会被上千个情境小对象复用，因此无需再重复存储数千个大对象的数据。
由于享元对象可在不同的情景中使用，必须确保其状态不能被修改。享元类的状态只能由构造函数的参数进行一次性初始化，它不能对其他对象公开其设置器或公有成员变量。为了能更方便地访问各种享元，可以创建一个工厂方法来管理已有享元对象的缓存池。工厂方法从客户端处接收目标享元对象的内在状态作为参数，如果它能在缓存池中找到所需享元，则将其返回给客户端；如果没有找到，它就会新建一个享元，并将其添加到缓存池中。