要解决的问题——面向对象的代价
面向对象很好地解决了系统抽象性的问题,同时在大多数的情况下也不会损及系统的性能。但是,在某些特殊的应用中,由于对象的数量太大,采用面向对象会给系统带来难以承受的系统开销。比如图形应用中的图元等对象,字处理应用中的字符对象等。
动机(Motivation)
采用纯粹对象方案的问题在于大量细粒度的对象会很快充斥在系统中,从而带来很高的运行时代价——主要指内存需求方面的代价。
如何在避免大量细粒度对象问题的同时,让外部客户程序仍然能够透明地使用面向对象的方式来进行操作?
意图(Intent)
运用共享技术有效地支持大量细粒度的对象。
——《设计模式》GoF
代码示例
class Charactor//36 Bytes
{
char c; //2 Bytes
Font f; //20 Bytes。如果直接new,代价比较大
//因此要改成以下方式:
private static Hashtable fontTable;
Font CFont
{
get{
return f;
}
set{
Font f = new Font(name,size,color);
if(fontTable.Keys.Exist(f))
{
this.f = fontTable.Keys[f];
}
else
{
fontTable.Keys.Add(value);
this.f = value;
}
}
}
}
class Font //20 Bytes
{
string fontName;
int size;
Color color;
//Font对象的Equals方法需要重写
}
class App
{
public static void Main()
{
ArrayList list = new ArrayList(10000000);
for(int i=0;i<list.count;i++)
{
Charactor c = new Charactor();
c.ahr = 'a';
//此处的Font相同,则内部指针指向相同
c.CFont = new Fond("宋体",5,Color.Red);
list.Add(c);
}
}
}
Flyweight模式的几个要点
1)面向对象很好地解决了抽象性的问题,但是作为一个运行在机器中的程序实体,我们需要考虑对象的代价问题。Flyweight设计模式主要解决面向对象的代价问题,一般不触及面向对象的抽象性问题。
2)Flyweight采用对象共享的做法来降低系统中对象的个数,从而降低细粒度对象给系统带来的内存压力。在具体实现方面,要注意对象状态的处理。
3)对象的数量太大从而导致对象内存开销加大——什么样的数量才算大?这需要我们仔细的根据具体应用情况进行评估,而不能凭空臆断。