享元模式

一、动机

1.在软件系统才用纯粹对对象方案的问题在于大量细粒度的对象会很快充斥在系统中，从而带来很高的运行时代价–主要指内存需求方面的代价

2.如何在避免大量细粒度对象问题的同事让外部客户程序仍然能够透明地使用面向对象的方式来进行操作？

二、介绍

意图： 运用共享技术有效地支持大量细粒度的对象。

主要解决： 在有大量对象时，有可能会造成内存溢出，我们把其中共同的部分抽象出来，如果有相同的业务请求，直接返回在内存中已有的对象，避免重新创建。

何时使用： 1、系统中有大量对象。 2、这些对象消耗大量内存。 3、这些对象的状态大部分可以外部化。 4、这些对象可以按照内蕴状态分为很多组，当把外蕴对象从对象中剔除出来时，每一组对象都可以用一个对象来代替。 5、系统不依赖于这些对象身份，这些对象是不可分辨的。

如何解决： 用唯一标识码判断，如果在内存中有，则返回这个唯一标识码所标识的对象。

关键代码： 用 HashMap 存储这些对象。

应用实例： 1、数据库的数据池。

优点： 大大减少对象的创建，降低系统的内存，使效率提高。

缺点： 提高了系统的复杂度，需要分离出外部状态和内部状态，而且外部状态具有固有化的性质，不应该随着内部状态的变化而变化，否则会造成系统的混乱。

使用场景： 1、系统有大量相似对象。 2、需要缓冲池的场景。

注意事项： 1、注意划分外部状态和内部状态，否则可能会引起线程安全问题。 2、这些类必须有一个工厂对象加以控制。

三、结构

四、要点总结

1.面向对象很好地解决了抽象性的问题，但是作为一个运行在机器中的程序实体，我们需要考虑对象的代价问题。Flyweight主要解决面向对象的代价问题，一般不触及面向对象的抽象性问题。

2.Flyweight采用对象共享的做法来降低系统中对象的个数，从而降低细粒度对象给系统带来的内存压力。在具体实现方面，要注意对象状态的处理。

3.对象的数量太大从而导致对象内存开销加大—一什么样的数量才算大？这需要我们仔细的根据具体应用情况进行评估，而不能凭空臆断。

五、代码展示

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(){
        //...
    }
};