文章目录
享元(Flyweight)模式
隶属类别——对象结构型模式
1. 意图
运用共享计数有效地支持大量细粒度的对象。
2. 别名
无
3. 动机
有些应用程序得益于在其整个设计过程中采用对象技术,但是简单化的实现代价太大。
例如,大多数文档编辑器的实现都有文本格式化和编辑功能,这些功能在一定程度上是模块化的。面向对象的文档编辑器通常使用对象来表示嵌入的成分,例如表格和图像。尽管用对象来表示文档中的每个字符会极大地提高应用程序的灵活性,但是这些编辑器通常不这样做。字符和嵌入成分可以在绘制和格式化时统一处理。从而在不影响其他功能的情况下能对应用程序进行扩展,支持新的字符集。应用程序的对象结构可以模拟文档的物理结构。下图显示了一个文档编辑器怎样使用对象来表示字符。
但是这种设计的缺点在于代价太大。即使是一个中等大小的文档也可能要求成百上千的字符对象,这样会耗费大量内存,产生难以的运行开销。所以通常并不是对每个字符都用一个对象来表示的。Flyweight模式描述了如何共享对象,使得细粒度地使用它们而无需高昂的代价。
Flyweight是一个共享对象,它可以同时在多个场景或称为上下文(context)中使用,并且在每个场景中Flyweight都可以作为一个独立的对象——这一点与非共享的实例没有区别,Flyweight不能对它所运行的场景做出任何假设,这里的关键概念是内部状态和外部状态之间的区别。内部状态存储于Flyweight中,它包含了独立于context场景的信息,这些信息使得flyweight可以被共享。而外部状态取决于context场景,并根据场景而变化,因此不可共享。用户负责在必要的时候将外部状态传递给Flyweight.
Flyweight模式对那些通常因为数量太大而难以用对象来表示的概念或实体进行建模。例如,文档编辑器可以为字母表中的每一个字母创建一个Flyweight。每个Flyweight存储一个字符代码,但它在文档中的位置和排版风格可以在字符出现时由正文排版算法和使用的格式化命令决定。字符代码是内部状态,而其他的信息则是外部状态。
逻辑上,文档中的每个给定字符每次出现都有有一个对象与其对应,如下图所示:
然而,物理上每个字符共享一个Flyweight对象,而这个对象出现在文档结构中的不同地方。一个特定字符对象的每次出现都指向同一个实例,这个实例位于Flyweight对象的共享池中。
这些对象的类结构如下图所示。Glyph是图形对象的抽象类,其中部分对象可能是Flyweight。基于外部状态的那些操作将外部状态作为参量传递给它们。例如,Draw和Intersects在执行之前,必须知道Glyph所在的context。
表示字母"a"的Flyweight只存储相应的字符代码;它不需要存储字符的位置或者字体。用户提供与context相关的信息,根据此信息Flyweight绘出它自己。例如,Row 知道它的children应该在哪个位置才能保证它们是横向排列的。因此Row 可以在绘制请求中向每一个子女传递它的位置。
由于不同的字符对象数远小于文档中的字符数,因此,对象的总数远小于一个初次执行的程序所使用的对象数目。对于一个所有字符都使用相同的字体和颜色的文档而言,不管这个文档有多长,只需要分配100个左右的字符对象(大约是ASCⅡ字符集的数目)。由于大多数文档使用的字体颜色组合不超过10种,实际应用中这一数目不会增加。因此对单个字符进行对象抽象具有实际意义的。
4. 适用性
Flyweight模式的有效性很大程度取决于如何使用它以及在何处使用它。当以下情况都成立!!!!!时使用Flyweight模式:
- 一个应用程序使用了大量的对象。
- 完全由于使用大量的对象,造成很大的存储开销。
- 对象的大多数状态都可变为外部状态。
- 如果删除对象的外部状态,那么可以用相对较少的共享对象取代很多组对象。
- 应用程序不依赖于对象标识()。由于Flyweight对象可以被共享,对于概念上明显有别的对象,标识测试将返回真值
5. 结构
下面的对象图说了如何共享Flyweight(由于实在不知道这是什么图,没找到能绘出这种图的工具,就引用原文把)。
6. 参与者
- Flyweight(Glyph)
- 描述一个接口,通过这个接口flyweight可以接受并作用于外部状态。
- ConcreteFlyweight(Character)
- 实现Flyweight接口,并未内部状态(如果有的话)增加存储空间。ConcreteFlyweight对象必须是可共享。它所存储的状态必须是内部的;即它必须独立于ConcreteFlyweight对象的场景。
- UnsharedConcreteFlyweight(Row, Column)
- 并非所有的Flyweight子类都需要被共享。Flyweight接口使共享成为可能,但它并不强制共享。在Flyweight对象结构的某些层次,UnsharedConcreteFlyweight对象通常将ConcreteFlyweight对象作为子节点(Row和Column就是这样)
- FlyweightFactory
- 创建并管理Flyweight对象
- 确保合理地共享flyweight。当用户请求一个Flyweight时,FlyweightFactory对象提供一个已创建的实例或者创建一个(如果不存在的话)
- Client
- 维持一个对flyweight的引用。
- 计算或存储一个(或多个)flyweight的外部状态。
7. 协作
- Flyweight执行时所需的状态必定是内部的或外部的。内部状态存储于ConcreteFlyweight对象之中;而外部对象而Client对象存储或计算。当用户调用flyweight对象的操作时,将该状态传递给它
- 用户不应该对ConcreteFlyweight类进行实例化,而只能从FlyweightFactory对象得到ConcreteFlyweight对象,这可以保证对它们适当地进行共享
8. 效果
使用Flyweight模式时,传输,查找和/或计算外部状态都会产生运行时的开销,尤其当Flyweight原先已经存储为内部状态是。然而,空间上的节省抵消了这些开销。共享的Flyweight越多,节省的空间也就越大。
存储节约由以下几个因素决定:
-
因为共享,实例总数数目的减少
-
对象内部状态的平均数目
-
外部状态是计算的还是存储的
共享的Flyweight越多,存储节约也就越多。节省量随着内部共享状态的增加而增大。当对象使用大量的内部状态及内状态,而且外部状态是计算出来的而非存储的时候,节约量将达到最大。所以,可以用两种方法来节省存储:
-
- 用共享减少内部状态的消耗
-
- 用计算时间换取对外部状态的存储。
-
Flyweight模式经常和Composite模式结合起来表示一个层次式结构,这一层次式结构时一个共享叶节点的图。共享的结果是,Flyweight的叶节点不能存储指向父节点的指针。而将父节点的指针作为Flyweight的外部状态的一部分传给Flyweight。这对于该层次结构中对象之间相互通讯的方式将产生很大的影响。
9. 实现
在实现Flyweight模式时,注意以下几点:
-
- 删除外部状态 该模式的可用性在很大程度上取决于是否容易识别外部状态并将它从共享对象中删除。如果不同种类的外部状态和共享前对象的数目相同的话(例如是十个外部状态且共享前有十个对象),删除外部状态不会降低存储消耗。理想的状况是,外部状态可以由一个单独的对象结构计算得到,且该结构的存储要求非常小
例如,在我们的文档编辑器,我们可以用一个单独的结构存储排版布局信息,而不是存储每一个字符对象的字体和类型信息,布局图保持了相同排版信息的字符的运行轨迹。当某个字符绘制自己的时候,作为绘图遍历的副作用它接受排版信息,因为通常文档使用的字符和类型数量有限,将该信息作为外部信息来存储,要比内部存储高效得多。
-
1)管理共享对象 因为对象时共享的,用户不能直接对它进行实例化,因为Fly-weight-Factory可以帮助用户查找感兴趣的得Flyweight对象。FlyweightFactory对象经常使用关联存储帮助用户查找感兴趣的Flyweight对象。例如,在这个文档编辑器毅力中的Flyweight工厂就有一个以字符代码为索引的Flyweight表(我用的是Map)。管理程序根据所给的Key参数返回相应的Fly-weight,如不存在,则创建一个Flyweight。
共享还意味着某种形式的引用计数和垃圾回收,这样当一个Flyweight不再使用时,可以回收它的存储空间。然而,当Flyweight的数目固定而且很小的时候(例如,用于ASCⅡ的Flyweight), 这两种操作都不必要。 在这种情况下,Flyweight完全可以永久保存。
10. 代码示例
首先是Flyweight——Tree.java
public interface Tree {
void display(int x,int y,int age);
}
两个ConcreteFlyweight——PineTree.java & PoplarTree.java
PineTree.java
public class PineTree implements Tree {
// intrinsic State
private int count = 10;
public PineTree() {
System.out.println("displaying a PineTree ");
// adding the delay
try {
Thread.sleep(5000);
}catch (InterruptedException e) {
e.printStackTrace();
}
}
// x,y,age are extrinsic state.
@Override
public void display(int x, int y, int age) {
System.out.println(this + " is at x :" + x + " y : " + y + " age :" + age + " count :" + count);
}
@Override
public String toString() {
return "PineTree";
}
}
PoplarTree.java
public class PoplarTree implements Tree {
public PoplarTree() {
System.out.println("diplaying a PolarTree");
// adding the delay
try {
Thread.sleep(5000);
}catch (InterruptedException e) {
e.printStackTrace();
}
}
// x,y,age are extrinsic state.
@Override
public void display(int x, int y, int age) {
System.out.println(this + " is at x :" + x + " y : " + y + " age :" + age);
}
@Override
public String toString() {
return "PoplarTree";
}
}
以及它们类型对应的枚举——TreeType.java
public enum TreeType {
PINETREE,POPLARTREE;
}
接下来是FlyweightFactory——TreeManager.java
public class TreeFactory {
// initialize FlyweightPool
private static final HashMap<TreeType, Tree> map = new HashMap<>();
public static Tree getTree(TreeType type) {
Tree tree = map.get(type);
if (tree == null) {
if (type == TreeType.PINETREE) {
tree = new PineTree();
} else if (type == TreeType.POPLARTREE) {
tree = new PoplarTree();
}
map.put(type, tree);
}
return tree;
}
}
最后是Client——TreeManager.java
public class TreeManager {
private Random rand = new Random(System.currentTimeMillis());
public void make() {
for (int i = 0; i < 30; i++) {
Tree tree = TreeFactory.getTree(getRandomType());
tree.display(getRandomX(), getRandomY(), getRandomAge());
}
}
public TreeType getRandomType() {
TreeType tree = null ;
switch (rand.nextInt(2)) {
case 0 : tree = TreeType.PINETREE; break;
case 1 : tree = TreeType.POPLARTREE; break;
default : ;
}
return tree;
}
private int getRandomX() {
return (int) (rand.nextInt(20) * 30);
}
private int getRandomY() {
return (int) (rand.nextInt(30) * 30);
}
private int getRandomAge() {
return (int) (rand.nextInt(30));
}
public static void main(String[] args) {
TreeManager manager = new TreeManager();
manager.make();
}
}
这里我创建30个对象进行计算。对应的测试结果:
displaying a PineTree
PineTree is at x :180 y : 120 age :16 count :10
PineTree is at x :330 y : 330 age :17 count :10
PineTree is at x :90 y : 750 age :25 count :10
diplaying a PolarTree
PoplarTree is at x :510 y : 660 age :5
PoplarTree is at x :30 y : 690 age :3
PoplarTree is at x :30 y : 810 age :0
PineTree is at x :270 y : 270 age :15 count :10
PoplarTree is at x :510 y : 60 age :26
PineTree is at x :210 y : 420 age :11 count :10
PineTree is at x :240 y : 180 age :17 count :10
PoplarTree is at x :450 y : 300 age :17
PoplarTree is at x :30 y : 870 age :12
PoplarTree is at x :270 y : 780 age :2
PineTree is at x :360 y : 390 age :10 count :10
PineTree is at x :30 y : 120 age :29 count :10
PoplarTree is at x :570 y : 690 age :10
PoplarTree is at x :450 y : 210 age :28
PoplarTree is at x :390 y : 840 age :4
PineTree is at x :360 y : 0 age :28 count :10
PoplarTree is at x :420 y : 360 age :9
PineTree is at x :210 y : 330 age :26 count :10
PoplarTree is at x :30 y : 660 age :1
PineTree is at x :360 y : 780 age :27 count :10
PineTree is at x :120 y : 420 age :28 count :10
PineTree is at x :120 y : 90 age :13 count :10
PoplarTree is at x :210 y : 0 age :16
PoplarTree is at x :540 y : 150 age :20
PineTree is at x :240 y : 120 age :8 count :10
PineTree is at x :420 y : 810 age :9 count :10
PoplarTree is at x :120 y : 870 age :20
在第一次生成PoplarTree树和PineTree都要等待五秒的延迟,当之后生成的时候,就不需要等待了,可以生成。
这里附上类的UML图:(这里解释一下有在TreeManager我使用的是TreeFactory的静态方法进行创建Tree,所以类图与结构中提到的并非完全一致):
11. 已知应用
Flyweight的概念最先是在InterView 3.0[CL90]中提出并作为一种设计技术得到研究。它的开发者构建了一个强大的文档编辑器Doc, 作为flyweight概念的论证。Doc使用符号对象来表示文档中的每一个字符。编辑器为每一个特定类型的字符创建一个Glyph实例;所以,一个字符的内部包括字符代码和类型信息(类型表的索引)。这意味着只有位置是外部状态,这使得Doc运行很快。文档由类Document表示,它同时也是一个FlyweightFactory。对Doc的测试表明共享Flyweight字符是高效得。通常,一个包含180 000个字符的文档只要求分配大约480个字符对象。
12. 相关模式
- Composite模式:Flyweight模式通常和Composite模式结合起来,用共享叶节点的有向无环图实现一个逻辑上的层次结构。
- State模式&Strategy模式:通常最好使用Flyweight实现State和Stategy模式。
13. 设计原则口袋
- 封装变化
- 针对接口编程,不针对实现编程
- 多用组合,少用继承
- 为交互对象的松耦合设计而努力
- 类应该对扩展开放,对修改关闭
- 依赖抽象,不要依赖具体类
- 只有密友交谈
- 好莱坞原则——别来找我,我会来找你
- 单一责任原则——类应该只有一个改变的理由
14. 参考文献
《设计模式:可复用面向对象软件的基础》
《HeadFirst设计模式》