3.2 《硬啃设计模式》第11章 森林里的树太多了！- 轻量模式(FlyWeight Pattern)

本文主要是介绍3.2 《硬啃设计模式》第11章 森林里的树太多了！- 轻量模式(FlyWeight Pattern)，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

有一个森林模拟 软件 ，能随机生成几十种不同数量的树木，并在屏幕中绘制出来。

示意图如下：

 

该“森林系统”的设计如下：

 

这个设计的好处：
1.所有树都被抽象成Tree，方便管理。
2.每一个树都是单独的对象，用起来比较爽。

可是问题来了，当数目数量很大的时候，这些树消耗掉大量的内存，程序就越跑越慢了！
我们希望每一个树还是一个对象，但又不希望内存消耗过大，你有什么解决办法呢？

问题分析：
1.请留意抽象类Tree，Tree有Color、Location、Shape属性。
2.请留意示意图，对于同一类型的树除了Location，它们的Color、Shape其实是一样的，这样如果有1万棵相同类型的树，那么这些树的Color、Shape就会被重复保存了1万分，实在没有必要。
3.有什么办法能share这些Color、Shape，同时又能保证每一个树还是一个独立的对象呢？

轻量模式也会叫做享元模式，之所以叫享元就是在于“享”这个字！看看应用了轻量模式后的设计：

 

说明：
1.Location作为外部状态来管理，Location不再放入Tree中，原来的Tree也变成了FlyweightTree了，FlyweightTree只存放共享部分的内容。
2.FlyweightTree仍然有Draw()方法，但需要传入ExternalState(也就是Location的信息)，这样就可以根据本身内置的信息(Color,Shape)加上外部信息(Location)把树画出来。
3.Client不能直接得到一个树对象，需要通过TreeFactory的GetTree()方法得到，GetTree()在树池中判断是否存在同品种的树，存在则返回该树，否则就新建一棵树。
4.这样的设计，会让所有同品种的树共享相同的FlyweightTree，对于Client来说，它不知道也不需要知道得到的树是“共享”的还是“独占”的。
5.树的位置是每棵树独有的，没有办法共享，不能放在FlyweightTree中，需要抽出来放到外部管理，这些不能共享的树的状态，叫做外部状态(ExternalState).

下面是轻量模式的 类图 ：

 

说明：
1.希望“面向对象”地处理大量实例，又不想内存消耗太大时，可考虑轻量模式。
2.共享策略、外部状态的管理是轻量模式的难点。

3.实例间没有可“共享”的东西时，不适用轻量模式。

这篇关于3.2 《硬啃设计模式》第11章 森林里的树太多了！- 轻量模式(FlyWeight Pattern)的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！

---