Flyweight享元模式是一种“对象性能”模式
- 面向对象很好地解决了“抽象”的问题,但是必不可免地要付出一定的代价。对于通常情况来说,面向对象的成本大都可以忽略不计。但是某些情况,面向对象所带来的成本必须谨慎处理
动机
- 在软件系统采用纯粹对象方案的问题在于大量细粒度的对象会很快充斥在系统中,从而带来很高的运行时代价——主要指内存需求方面的代价
- 如何在避免大量细粒度对象问题的同时,让外部客户程序仍然能够透明地使用面向对象的方式来进行操作?
定义
- 运用共享技术有效地支持大量细粒度的对象
结构
代码对比
flyweight.cpp
class Font {
private:
//unique object key
string key;
//object state
//....
public:
Font(const string& key){
//...
}
};
ß
class FontFactory{
private:
map<string,Font* > fontPool;
public:
Font* GetFont(const string& key){
map<string,Font*>::iterator item=fontPool.find(key);
if(item!=footPool.end()){
return fontPool[key];
}
else{
Font* font = new Font(key);
fontPool[key]= font;
return font;
}
}
void clear(){
//...
}
};
对比
- 程序在
FontFactory
中定义了一个map<string, Font*>
类型的字体池,用于共享各种字体类型,如果输入的key
在字体池中找到了,就说明之前创建过这种对象,直接返回该对象;如果key
没有找到,就创建这种新对象,并添加到对象池中。这样同一种key
在系统中只会创建一个字体对象(共享的方式)
要点总结
- 面向对象很好地解决了抽象性的问题。但是作为一个运行在机器中的程序实体,我们需要考虑对象的代价问题。Flyweight主要解决面向对象的代价问题,一般不触及面向对象的抽象性问题
- Flyweight采用对象共享的做法来降低系统中对象的个数,从而降低细粒度对象给系统带来的内存压力。在具体实现方面,要注意对象状态的处理
- 对象的数量太大从而导致对象内存开销加大——什么样的数量才算大?这需要我们仔细地根据具体应用情况进行评估,而不能凭空臆断
来源:CSDN
作者:Felix_hyfy
链接:https://blog.csdn.net/Felix_hyfy/article/details/104638012