C++設計形式之單例形式。本站提示廣大學習愛好者：（C++設計形式之單例形式）文章只能為提供參考，不一定能成為您想要的結果。以下是C++設計形式之單例形式正文
問題描繪
如今，不論開發一個多大的零碎（至多我如今的部門是這樣的），都會帶一個日志功用；在實踐開發進程中，會專門有一個日志模塊，擔任寫日志，由於在零碎的任何中央，我們都有能夠要調用日志模塊中的函數，停止寫日志。那麼，如何結構一個日志模塊的實例呢？難道，每次new一個日志模塊實例，寫完日志，再delete，不要通知我你是這麼干的。在C++中，可以結構一個日志模塊的全局變量，那麼在任何中央就都可以用了，是的，不錯。但是，我所在的開發部門的C++編碼標准是參照Google的編碼標准的。
全局變量在項目中是能不必就不必的，它是一個定時炸彈，是一個不平安隱患，特別是在多線程順序中，會有很多的不可預測性；同時，運用全局變量，也不契合面向對象的封裝准繩，所以，在純面向對象的言語Java和C#中，就沒有地道的全局變量。那麼，如何完滿的處理這個日志問題，就需求引入設計形式中的單例形式。
單例形式
何為單例形式，在GOF的《設計形式：可復用面向對象軟件的根底》中是這樣說的：保證一個類只要一個實例，並提供一個訪問它的全局訪問點。首先，需求保證一個類只要一個實例；在類中，要結構一個實例，就必需調用類的結構函數，如此，為了避免在內部調用類的結構函數而結構實例，需求將結構函數的訪問權限標志為protected或private；最後，需求提供要給全局訪問點，就需求在類中定義一個static函數，前往在類外部獨一結構的實例。意思很明白，運用UML類圖表示如下。
UML類圖
代碼完成
單例形式，單從UML類圖下去說，就一個類，沒有撲朔迷離的關系。但是，在實踐項目中，運用代碼完成時，還是需求思索很多方面的。
完成一：
C++中的RAII機制》。
形式擴展
在實踐項目中，一個形式不會像我們這裡的代碼那樣復雜，只要在純熟了各種設計形式的特點，才干更好的在實踐項目中停止運用。單例形式和工廠形式在實踐項目中常常見到，兩種形式的組合，在項目中也是很罕見的。所以，有必要總結一下兩種形式的結合運用。
一種產品，在一個工廠中停止消費，這是一個工廠形式的描繪；而只需求一個工廠，就可以消費一種產品，這是一個單例形式的描繪。所以，在實踐中，一種產品，我們只需求一個工廠，此時，就需求工廠形式和單例形式的結合設計。由於單例形式提供對外一個全局的訪問點，所以，我們就需求運用復雜工廠形式中那樣的辦法，定義一個標識，用來標識要創立的是哪一個單件。由於模仿代碼較多，在文章最後，提供下載鏈接。
總結
為了寫這篇文章，自己調查了很多方面的材料，由於網上的材料在各方面都有很多的瑕疵，質量參次不齊，對我也形成了一定的誤導。而這篇文章，有我自己的了解，如有錯誤，請大家指正。
由於該文對設計形式的總結，我以為比網上80%的都片面，希望對大家有用。在實踐的開發中，並不會用到單例形式的這麼多種，每一種設計形式，都應該在最合適的場所下運用，在日後的項目中，應做到有地放矢，而不能為了運用設計形式而運用設計形式。
工程下載
