今天差点就不想坚持学习了，不过 还是 觉得 要坚持。 明天后天更要坚持。。 加油！
享元模式以共享的方式高效的支持大量的细粒度对象。享元对象能做到共享的关键是区分内蕴状态（Internal State）和外蕴状态（External State）。内蕴状态是存储在享元对象内部并且不会随着环境改变而改变。因此内蕴状态才可以共享。
外蕴状态是随着环境改变而改变的，不可以共享的状态。享元对象的外蕴状态必须由客户端保存，并在享元对象被创建之后，在需要使用的时候再传入到享元对象内部。外蕴状态与内蕴状态是相互独立的。
享元模式结构：
抽象享元角色（Flyweght）：：此角色是所有的具体享元类的超类，为这规定出需要实现的公共接口。那些需要外蕴状态(External State)的操作可以通过调用商业方法以参数形式传入。
具体享元角色（ConcreteFlyweight）：实现抽象享元角色所规定的接口。如果有内蕴状态的话，必须负责为内蕴状态提供存储空间。享元对象的内蕴状态必须与对象所处的周围环境无关，从而使得享元对象可以在系统内共享的。
享元工厂角色（FlyweightFactory）：本角色负责创建和管理享元角色。本角色必须保证享元对象可以被系统适当地共享。当一个客户端对象调用一个享元对象的时候，享元工厂角色会检查系统中是否已经有一个复合要求的享元对象。如果已经有了，享元工厂角色就应当提供这个已有的享元对象；如果系统中没有一个适当的享元对象的话，享元工厂角色就应当创建一个合适的享元对象。
客户端角色（Client）：本角色需要维护一个对所有享元对象的引用。本角色需要自行存储所有享元对象的外蕴状态。
复合享元模式的结构：
单纯享元模式中，所有的享元对象都可以直接共享。
说明：
享元模式应当在什么情况下使用 ：
1.一个系统有大量的对象。
2.这些对象耗费大量的内存。
3.这些对象的状态中的大部分都可以外部化。
4.这些对象可以按照内蕴状态分成很多的组，当把外蕴对象从对象中剔除时，每一个组都可以仅用一个对象代替。
5.软件系统不依赖于这些对象的身份，换言之，这些对象可以是不可分辨的。
最后，享元模式需要维护一个记录了系统已有的所有享元的表，而这需要耗费资源。因此，应当在有足够多的享元实例可供共享时才值得使用享元模式。
享元模式的优点和缺点：
1.享元模式使得系统更加复杂。为了使对象可以共享，需要将一些状态外部化，这使得程序的逻辑复杂化。
2.享元模式将享元对象的状态外部化，而读取外部状态使得运行时间稍微变长。
总结：总原理上来看 这个享元模式 好像有点像单例模式，都是将一个实例化的新对象存储到一个容器中，当下次需要使用的时候 可以直接拿去使用，而不需要从新实例化，然而不同的地方在于，在里可以根据环境的变化，实例化多个不同的对象统一放到一个集合中，当要使用的时候可以在集合中寻找现有的对象。从而达到了一个共享的作用。好像在开发过程中没怎么遇到过这总需求哈，除非很多类 都很常用，并且这些类里面 都不包含业务属性。 要不然 如果公用的话业务就串了。。