标签： 设计模式初涉

场景引入

有时在开发中，可能我们需要创建大量的相同的重复对象，比如游戏开发中，
场景贴图的，一个森林的场景，要有有成千上万的树，如果为每棵树都实例化
不同的模型，估计会把你电脑给炸了。使用享元模式可以解决这个问题，
抽取出所有树对象的共有属性，并转移到一个单独的类中，然后只需要
一个示例就可以了，然后森林里的每棵树对这个实例做一次引用：

笔者对游戏开发不太了解，这里只是打个比方，关于具体内容
可参看原文：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