设计模式 第二周学习笔记

对象性能模式

• 面向对象很好地解决了抽象的问题，但是不可避免的要付出一定的代价，对于通常情况来讲，面向对象的成本大多可以忽略不计。但是某些情况，面向对象所带来的成本必须谨慎处理。
• 典型模式
  singleton
  Flyweight

singleton

Motivation：

• 在软件系统中，经常有这样一些特殊的类，必须保证它们在系统中只存在一个实例，才能确保它们的逻辑正确性，以及良好的效率。
• 如何绕过常规的构造器，提供一种机制来保证一个类只有一个实例？
• 这应该是类设计者的责任，而不是使用者的责任。

模式定义
保证一个类仅有一个实例，并提供一个该实例的全局访问点。
————《设计模式》GoF

实现：

class Singleton{
private:
    Singleton();
    Singleton(const Singleton& other);
public:
    static Singleton* getInstance();
    static Singleton* m_instance;
};

Singleton* Singleton::m_instance=nullptr;

实现方法即将该类的默认构造函数和拷贝构造函数均声明为private，随后在public里面声明两个静态接口访问它。

线程非安全版本：

Singleton* Singleton::getInstance() {
    if (m_instance == nullptr) {
        m_instance = new Singleton();
    }
    return m_instance;
}

该方法通过静态接口访问构造器，通过nullptr判断类是否被初始化过。
notice:
该方法仅在单线程下适用，在多线程版本时，由于可能存在多个线程同时访问m_instance，这时就会创建出多个对象出来。
线程安全版本：

Singleton* Singleton::getInstance() {
    Lock lock;
    if (m_instance == nullptr) {
        m_instance = new Singleton();
    }
    return m_instance;
}

该版本在线程进入读写m_instance之前添加互斥锁，保证了在同一时间只有单一线程对该对象进行读写，保证了线程安全。
notice：
该互斥锁虽然防止了多个线程对对象的同时创建，但是，当对象创建完毕时，多线程读取操作也会由于该互斥锁的存在不得不进入线程队列，这带来了额外的性能开销。

双检查锁：

Singleton* Singleton::getInstance() {
    
    if(m_instance==nullptr){
        Lock lock;
        if (m_instance == nullptr) {
            m_instance = new Singleton();
        }
    }
    return m_instance;
}

使用双检查锁，该锁对对象的读取操作并没有阻止，只是防止了多线程对对象的创建操作。
notice：
该版本虽然看起来安全，但是由于内存读写reorder。即由于编译器自动优化导致的先将申请到的内存绑定给m_instance却还未执行构造器。这时m_instance所指向的内存是未定义的，此时若另一个线程调用getInstance时，由于m_instance非nullptr，则会将这个未初始化的内存直接返回，产生未定义行为。

在msvc平台下微软定义了volatile关键字，可使用volatile关键字修饰m_instance阻止编译器自动优化，但是该方法并不跨平台。

c++11之后的跨平台实现：

std::atomic<Singleton*> Singleton::m_instance;
std::mutex Singleton::m_mutex;

Singleton* Singleton::getInstance() {
    Singleton* tmp = m_instance.load(std::memory_order_relaxed);
    std::atomic_thread_fence(std::memory_order_acquire);//获取内存fence
    if (tmp == nullptr) {
        std::lock_guard<std::mutex> lock(m_mutex);
        tmp = m_instance.load(std::memory_order_relaxed);
        if (tmp == nullptr) {
            tmp = new Singleton;
            std::atomic_thread_fence(std::memory_order_release);//释放内存fence
            m_instance.store(tmp, std::memory_order_relaxed);
        }
    }
    return tmp;
}

• 结构

要点总结

• singleton模式中的实例构造器可以设置为protected以允许子类派生。
• singleton模式一般不要支持靠白构造函数和Clone接口，因为这有可能导致多个对象实例，与singleton模式的初衷违背。
• 如何实现多线程环境下安全的singleton，注意对双检查锁的正确实现。

Flyweight享元模式

motivation：

• 在软件系统采用纯粹对象方案的问题在于大量细粒度的对象会很快充斥在系统中，从而带来很高的运行时代价—————主要指内存需求方面的代价。
• 如何在避免大量细粒度对象问题的同时，让外部客户程序仍然能够透明地使用面向对象的方式来进行操作。

模式定义：
运用共享技术有效地支持大量细粒度的对象。
——————《设计模式》GoF
以下为实例

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

该方法通过map构建了一个字体格式池，通过fontFactory对象来从格式池中取用模板，若不存在该格式则新建一个改格式并添加到格式池中再返回。该模式主要就是通过fontfactory实现了对象的共享，避免了相同对象的重复创建，提高了性能。
structre

• 要点总结
• 面向对象很好地解决了抽象的问题，但是作为一个运行在机器中的程序体，我们需要考虑对象的代价问题，Flyweight主要解决面向对象的代价问题，一般不触及面向对象的抽象性问题。
• Flyweight采用对象共享的做法来降低系统中对象的个数，从而降低细粒度对象给系统带来的内存压力。在具体实现方面，要注意对象状态的处理。
• 对象的数量太大从而导致对象内存开销加大————什么样的数量才算大？这需要我们仔细的根据具体应用情况进行评估，而不能凭空臆断。