C++设计模式——享元模式Flyweight-Pattern
动机(Motivation)
- 在软件系统采用纯粹对象方案的问题在于大量细粒度的对象会很快充斥在系统中,从而带来很高的运行时代价——主要指内存需求方面的代价。
- 如何在避免大量细粒度对象问题的同时,让外部客户程序仍然能够透明地使用面向对象的方式来进行操作?
模式定义
运行共享技术有效地支持大量细粒度的对象。 ——《设计模式》GoF
结构(Structure)
模式举例
假设要设计一个字处理系统,如果每一个字符都是对象,一篇文章将会有太多对象了 但将这些字符按照字体分类,那么仅会有几种字体对象
//该模式解决的不是抽象问题而是性能问题 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() { //... } };
要点总结
- 面向对象很好地解决了抽象性的问题,但是作为yield运行机器中的程序实体,我们需要考虑对象的代价问题, Flyweight主要解决面向对象的大家问题,一般不触及面向对象的抽象性问题。
- Flyweight采用对象共享的做法来降低系统中对象的个数,从而降低细粒度对象给系统带来的压力。在具体实现方面,要注意对象状态的处理。
- 对象的数量太大从而导致对象内存开销加大——什么样的数量才算大?这需要我们仔细的根据具体应用情况进行评估,而不能凭空臆断。
基本代码
#include#include
享元模式可以避免大量非常相似的开销。在程序设计中,有时需要生成大量细粒度的类实例来表示数据。如果能发现这些实例除了几个参数外基本上都是相同的,有时就能够大幅度地减少需要实例化的类的数量。如果能把那些参数移到类实例的外面,在方法调用时将它们传递进来,就可以通过共享大幅度地减少单个实例的数目。
- 如果一个应用程序使用了大量的对象,而这些对象造成了很大的存储开销时就应该考虑使用享元模式;
- 对象的大多数状态可以是外部状态,如果删除对象的外部状态,那么可以用相对较少的共享对象取代很多组对象,此时可以考虑用享元模式。