C++常考筆試題:用C++實現單例模式

Q:什麼是單例模式?用C++語言實現(示範)一個單例模式.

 一、功能
　　保證一個類僅有一個執行個體。 
二、結構圖

三、優缺點
　　Singleton模式是做為"全域變數"的替代品出現的。所以它具有全域變數的特點：全域可見、貫穿應用程式的整個生命期，它也具有全域變數不具備的性質：同類型的對象執行個體只可能有一個。

    具體定義:

      單例模式Singleton,是最為常用的設計模式之一.單例模式也稱為單件模式、單子模式,它可以保證一個類僅有一個執行個體，並提供一個訪問它的全域訪問點，該執行個體被所有程式模組共用。有很多地方需要這樣的功能模組，如系統的日誌輸出，GUI應用必須是單滑鼠，MODEM的聯結需要一條且只需要一條電話線，作業系統只能有一個視窗管理器，一台PC連一個鍵盤。大多數的軟體都有一個（甚至多個）屬性（properties）檔案存放系統配置。這樣的系統應當由一個對象來管理一個屬性檔案。
需要管理的軟體內部資源也包括譬如負責記錄網站來訪人數的組件，記錄軟體系統內部事件、出錯資訊的組件，或是對系統的表現進行檢查的組件等。這些組件都必須集中管理，不可政出多頭。這些資源管理員構件必須只有一個執行個體，這是其一；它們必須自行初始化，這是其二；允許整個系統訪問自己這是其三。因此，它們都滿足單例模式的條件，是單例模式的應用。

    實現方法:

    單例模式有許多種實現方法，在C++中，甚至可以直接用一個全域變數做到這一點，但這樣的代碼顯的很不優雅。 使用全域對象能夠保證方便地訪問執行個體，但是不能保證只聲明一個對象也就是說除了一個全域執行個體外，仍然能建立相同類的本地執行個體。
《設計模式》一書中給出了一種很不錯的實現，定義一個單例類，使用類的私人靜態指標變數指向類的唯一執行個體，並用一個公有的靜態方法擷取該執行個體。
單例模式通過類本身來管理其唯一執行個體，這種特性提供瞭解決問題的方法。唯一的執行個體是類的一個普通對象，但設計這個類時，讓它只能建立一個執行個體並提供對此執行個體的全域訪問。唯一執行個體類Singleton在靜態成員函數中隱藏建立執行個體的操作。習慣上把這個成員函數叫做Instance()，它的傳回值是唯一執行個體的指標。

#include <iostream>using namespace std;class Singleton{  public:  static Singleton* getInstance(){     if(pInstance == NULL){     pInstance = new Singleton();     cout << "the Only One" << endl;     }     else{     cout << "an instance is running..." << endl;     }     return pInstance;  }  private:  //私人化建構函式,使得不能執行個體化,因為執行個體化時類外部無法訪問其內部的私人的建構函式  //而且不能繼承   Singleton(){};//分號有和無都正確  static Singleton* pInstance;};Singleton* Singleton::pInstance = NULL;int main(){//Singleton s; //編譯器提示錯誤,建構函式是私人的 Singleton *p1 = Singleton::getInstance();Singleton *p2 = Singleton::getInstance();}

使用者訪問唯一執行個體的方法只有getInstance()成員函數。如果不通過這個函數，任何建立執行個體的嘗試都將失敗，因為類的建構函式是私人的。getInstance()使用懶惰初始化，也就是說它的傳回值是當這個函數首次被訪問時被建立的。這是一種防彈設計所有getInstance()之後的調用都返回相同執行個體的指標：
Singleton* p1 =Singleton :: getInstance();
Singleton* p2 = p1->getInstance();
Singleton & ref = * Singleton :: getInstance();
對getInstance稍加修改，這個設計範本便可以適用於可變多執行個體情況，如一個類允許最多五個執行個體。
 
單例類Singleton有以下特徵：
它有一個指向唯一執行個體的靜態指標pInstance，並且是私人的；
它有一個公有的函數，可以擷取這個唯一的執行個體，並且在需要的時候建立該執行個體；
它的建構函式是私人的，這樣就不能從別處建立該類的執行個體。
 
大多數時候，這樣的實現都不會出現問題。有經驗的讀者可能會問，pInstance指向的空間什麼時候釋放呢？更嚴重的問題是，該執行個體的解構函式什麼時候執行？
如果在類的析構行為中有必須的操作，比如關閉檔案，釋放外部資源，那麼上面的代碼無法實現這個要求。我們需要一種方法，正常的刪除該執行個體。
可以在程式結束時調用getInstance()，並對返回的指標掉用delete操作。這樣做可以實現功能，但不僅很醜陋，而且容易出錯。因為這樣的附加代碼很容易被忘記，而且也很難保證在delete之後，沒有代碼再調用getInstance函數。
一個妥善的方法是讓這個類自己知道在合適的時候把自己刪除，或者說把刪除自己的操作掛在作業系統中的某個合適的點上，使其在恰當的時候被自動執行。
我們知道，程式在結束的時候，系統會自動析構所有的全域變數。事實上，系統也會析構所有的類的靜態成員變數，就像這些靜態成員也是全域變數一樣。利用這個特徵，我們可以在單例類中定義一個這樣的靜態成員變數，而它的唯一工作就是在解構函式中刪除單例類的執行個體。如下面的代碼中的Garbo類（Garbo意為垃圾工人）：

class Singleton{  public:  static Singleton* getInstance();  private:   Singleton(){}  static Singleton* pInstance;  //內嵌類  class Garbo{    public:    ~Garbo(){    if(Singleton::pInstance != NULL)delete Singleton::pInstance;    }  };  static Garbo garbo;};

類Garbo被定義為Singleton的私人內嵌類，以防該類被在其他地方濫用。
程式運行結束時，系統會調用Singleton的靜態成員Garbo的解構函式，該解構函式會刪除單例的唯一執行個體。
使用這種方法釋放單例對象有以下特徵：
在單例類內部定義專有的嵌套類；
在單例類內定義私人的專門用於釋放的靜態成員；
利用程式在結束時析構全域變數的特性，選擇最終的釋放時機；
使用單例的代碼不需要任何操作，不必關心對象的釋放。

進一步的討論

但是添加一個類的靜態對象，總是讓人不太滿意，所以有人用如下方法來重現實現單例和解決它相應的問題，代碼如下：
class Singleton
{
   //其他成員
   public:
       static Singleton &getInstance()
{
   static Singleton instance;
   return instance;
}
       private:
           Singleton() {};
};
使用局部靜態變數，非常強大的方法，完全實現了單例的特性，而且代碼量更少，也不用擔心單例銷毀的問題。
但使用此種方法也會出現問題，當如下方法使用單例時問題來了，
Singleton singleton = Singleton :: getInstance();
這麼做就出現了一個類拷貝的問題，這就違背了單例的特性。產生這個問題原因在於：編譯器會為類產生一個預設的建構函式，來支援類的拷貝。
最後沒有辦法，我們要禁止類拷貝和類賦值，禁止程式員用這種方式來使用單例，而是讓getInstance()函數返回一個指標而不是返回一個引用，函數的代碼改為如下：
static Singleton *getInstance()
{
static Singleton instance;
return &instance;
}
但我總覺的不好，為什麼不讓編譯器不這麼幹呢。這時我才想起可以顯示的生命類拷貝的建構函式，和重載 =操作符，新的單例類如下：
class Singleton
{
   //其他成員
   public:
       static Singleton &getInstance()
{
   static Singleton instance;
   return instance;
}
       private:
           Singleton() {};
           Singleton(const Singleton);
           Singleton & operate = (const Singleton&);
};
關於Singleton(const Singleton);和 Singleton & operate = (const Singleton&);函數，需要聲明成私用的，並且只聲明不實現。這樣，如果用上面的方式來使用單例時，不管是在友元類中還是其他的，編譯器都是報錯。
不知道這樣的單例類是否還會有問題，但在程式中這樣子使用已經基本沒有問題了。
（出處：http://snailbing.blogbus.com/logs/45398975.html）