标签： 设计模式初涉
场景引入
有时在开发中，可能我们需要创建大量的相同的重复对象，比如游戏开发中，
场景贴图的，一个森林的场景，要有有成千上万的树，如果为每棵树都实例化
不同的模型，估计会把你电脑给炸了。使用享元模式可以解决这个问题，
抽取出所有树对象的共有属性，并转移到一个单独的类中，然后只需要
一个示例就可以了，然后森林里的每棵树对这个实例做一次引用：
笔者对游戏开发不太了解，这里只是打个比方，关于具体内容
可参看原文：http://gameprogrammingpatterns.com/flyweight.html
想引出：当存在多个相同对象的时候，使用享元模式可以减少相同对象
创建引起的内存消耗，提高程序性能。
这里举个扑克牌的例子来帮助理解享元模式。
（这里假定没有大小王，只有52张牌，四种花色）
普通套路实现扑克牌程序
如果让你来实现一个简单的扑克牌程序，你的代码可能是这样：
牌有花色和大小，先创建一个牌类
然后初始化52张牌，然后随机发五张牌
输出结果：
好的，正常输出，但是却初始化了52个Card对象，真的有必要
创建那么多对象吗？如果使用享元模式需要创建几个对象？
我们来写下代码对比下！
享元模式实现扑克牌程序
抽取下牌共有的属性是：花色和大小，花色固定四种，不同是大小，
这里涉及到享元模式的内部状态和外部状态，这个等下讲。
写一个卡牌的父类，然后写四个花色的类继承父类
接着是最关键的享元工厂，创建并管理共享的享元对象，并提供访问享元对象的接口：
接着客户端调用，模拟发十张牌
输出结果：
好的，享元模式就是那么简单，接下来说下概念性的东西~
享元模式概念相关
概念定义
运用共享技术有效的支持大量细粒度的对象。
内部状态与外部状态
内部状态：固定不变可共享的的部分，存储在享元对象内部，比如这里的花色。
外部状态：可变不可共享的部分，一般由客户端传入享元对象内部，比如这里的大小。
三个角色
- Flyweight：享元对象的抽象父类或者接口，通过这个接口，享元对象可以接受并作用于外部状态；
- ConcreteFlyweight：具体享元实现对象，继承或实现Flyweight并为内部状态增加存储空间。
- FlyweightFactory：享元工厂，创建并管理共享的享元对象，并对外提供访问共享享元对象的接口。
UML类图
使用场景
- 1.系统有大量相同或者相似的对象，消耗大量内存
- 2.需要缓冲池
优缺点
- 优点：大大减少对象的创建，降低系统的内存，使效率提高
- 缺点：使得系统变得复杂，需要分离出内部状态和外部状态，这使得程序的逻辑复杂化。
本节代码：
https://github.com/coder-pig/DesignPatternsExample/tree/master/11.Flyweight%20Pattern
