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

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

示意图如下:

3.2 《硬啃设计模式》第11章 森林里的树太多了!- 轻量模式(FlyWeight Pattern)_第1张图片  

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

3.2 《硬啃设计模式》第11章 森林里的树太多了!- 轻量模式(FlyWeight Pattern)_第2张图片  

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

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

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

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

3.2 《硬啃设计模式》第11章 森林里的树太多了!- 轻量模式(FlyWeight Pattern)_第3张图片  

说明:
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).

下面是轻量模式的 类图

3.2 《硬啃设计模式》第11章 森林里的树太多了!- 轻量模式(FlyWeight Pattern)_第4张图片  

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

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



请看下一文……
 
 
 

作者:张传波

创新工场创业课堂(敏捷课程)讲师

软件研发管理资深顾问

CMMI首席专家

《火球——UML大战需求分析》作者

《硬啃设计模式》作者

www.umlonline.org创办人


你可能感兴趣的:(设计模式,UML,flyweight)