單例模式的幾點比較

單例模式和全域變數：

全域變數是最容易引起初學者興趣的了，在整個項目中，任何一個函數，每一行代碼都可以輕易訪問所有的全域變數，並且可以不用付出額外的代價，全域變數看起來就像是為懶惰的程式員設計的一條綠色通道，如果不想看到函數因為要與其他模組通訊而動輒很多參數，或者像給程式始末的關鍵資訊尋找一個最合適的儲存位置，那麼全域變數就是很好的解決方案

但是在項目中，全域變數肯定不少，這個時候，使用起來就會比較混亂，這個時候有一種方法就是建立一個類，其中都是可以使用的全域變數，當需要使用時，直接在類中添加就可以了，這個模式還是很好的，但是仍然有很多麻煩事

首先就是變數名的衝突，這個問題會使專案管理的成本大大增加，專案經理必須小心維護變數名規則，必須分析每一個變數的模組，程式還有肯定就是耦合度的問題了，這個全域變數大大增加了函數和模組之間的耦合度，訪問某個全域變數的多個函數被該變數牢牢結合在一起，無法拆分開來

還有初始化的順序，因為全域變數不可能保證相互之間遵循特定的初始化順序，這個對於類與對象的執行個體，構造方法的電泳的順序有時顯得非常重要了

多線程訪問也是問題，當多個並發的線程都需要訪問某些全域變數的時候，我們必須使用各種同步機制來保護這些變數，防止陷入並發衝突的泥潭

 

單件模式是建立型模式的一種，從一定程度上說，它可以成為全域變數的替代品，它的設計意圖是，保證一個類只有一個對象執行個體，並提供一個訪問的方法，這個時候我們可以將資料封裝在一個特殊的類中，然後這個類嚴格管理它的資料的唯一性，不允許程式員隨意建立這個類的對象執行個體（將構造器不公有化就可以了），便可以用它的靜態成員函數得到類的唯一對象執行個體資料

使用單件類最容易犯的錯誤就是按照以前的結構化程式設計的思路考慮問題，將全域變數作為模組之間共用資料的一個橋樑，把它們收集起來，放進一個單件類，這肯定是不對的，而應該是從系統中尋找那些類的特性，生存周期較長的類，改成單件類的形式，生存周期短的就封裝在一個需要使用的類中，便可以解決這個問題（比如，有一個drawLine的屬性，它只要用於類Line中，只要Line類的生存周期結束了，便不再需要，如果將drawLine的屬性耦合關係封裝在Line內部，就可以解決問題了）

最近在項目中用到了全域變數，雖然功能實現了，但是總感覺到有些地方不對勁，總感覺到有什麼不好或者隱患的地方，今天在看別人源碼的時候，終於發現了單例模式的功用，也體會到了別人為什麼要用單例模式了，用單例模式能夠很好解決我的疑問了。

單例模式與把這個類所有成員全都聲明為靜態比較

這裡暫且把單例模式限定為不是全用靜態函數實現的。（#add此種模式在一個普通函數中直接返回一個static對象）

1。使用的方便性：如果需要初始化工作，單例模式可以在建構函式裡面完成，全靜態函數的類需要一個額外的函數來完成初始化工作，而且使用者如果沒有調用這個initialize函數，那麼後續的操作就會有問題，建構函式會被預設調用，所以使用起來比較簡單，對使用者做出了最少的假設。

2。初始化時機：單例模式初始化比較靈活，可以在需要的時候初始化，而全靜態函數必然導致成員全為靜態成員，靜態成員是在編譯時間就初始化好了。如果初始化成本比較昂貴，並且程式裡面未必一定使用這個類，那這將是單例模式的一個很大優勢。順便說一下全域變數，全域變數的初始化順序是未指定的（#add 指的是不同檔案甚至不同模組，同一檔案中則按定義順序初始化---有可能這也僅是基於vs的使用經驗）。

例如 全域變數int a； int b；編譯器是先初始化a還是先初始化b？我想大家只能靠猜，或者在某個編譯器上實驗一下給出答案，一旦要是有個新編譯器，結果又會是什麼樣子呢？

3。最重要的區別：單例模式可以有多態，而全靜態類不能支援多態。