享元模式

面临问题：

一个系统有大量的对象。这些对象耗费大量的内存。由于对象的数量太大，采用面向对象会给系统带来难以承受的内存开销。比如图形应用中的图元等对象、字处理应用中的字符对象等。采用纯粹对象方案的问题在于大量细粒度的对象会很快充斥在系统中，从而带来很高的运行时代价------主要指内存需求方面的代价。

如何在避免大量细粒度对象问题的同时，让外部客户程序仍然能够透明地使用面向对象的方式来进行操作？

解决方案：

当对象的粒度太小的时候，大量对象将会产生巨大的资源消耗，因此考虑用共享对象(flyweight)来实现逻辑上的大量对象。Flyweight对象可用于不同的context中，本身固有的状态(内部状态)不随context发生变化，而其他的状态(外部状态)随context而变化

比如：一个文本编辑器往往会提供很多种字体，而通常的做法就是将每一个字母做成一个享元对象。享元对象的内蕴状态就是这个字母，而字母在文本中的位置和字模风格等其他信息则是外蕴状态。

例如：字母a可能出现在文本的很多地方，虽然这些字母a的位置和字模风格不同，但是所有这些地方使用的都是同一个字母对象。这样一来，字母对象就可以在整个系统中共享。

举个例子：

比如围棋有300颗棋子。用一般的设计模式,

创建一个类,每个棋子都用一个对象的话，那就会非常麻烦，并且各自定义各自在棋盘的位置.....等等

而使用 亨元模式 来实现的话,

就用两个对象 :一个黑,一个白。

这样就可以了,至于棋子的方位不同,那只是对象的不同的外部表现形式或者说是外部状态。

这样三百多个对象就减到了两个对象。

享元模式以共享的方式高效地支持大量的细粒度对象,

说的再具体一些是将所有具有相同状态的对象指向同一个引用,

从而解决了系统在创建大量对象时所带来的内存压力。

 Flyweight
 描述一个接口，通过这个接口flyweight可以接受并作
用于外部状态
 ConcreteFlyweight
 实现Flyweight接口，并为内部状态增加存储空间。必
须是可以共享的，存储的状态必须是内部的。
 UnsharedConcreteFlyweight
 不强制共享
 FlyweightFactory
 创建并管理flyweight对象
确保合理地共享flyweight，提供已创建的flyweight实
例或者创建一个(如果不存在的话)
 Client
 维持一个对flyweight的引用
 计算或存储一个(多个)flyweight的外部状态