1單例模式

在某些情況下，有些物件只需要一個就可以了，即每個類只需要一個例項。例如，一臺計算機上的可以連線多臺印表機，但是該計算機上的列印程式只能有一個，這裡就可以通過單例模式來避免兩個列印作業同時輸出到印表機中，即在整個的列印過程中只有一個列印程式的例項。

單例模式（單件模式）的作用就是保證在整個應用程式的生命週期中，任何一個時刻，單例類的例項都只存在一個（當然也可以不存在）。單例模式確保某一個類只有一個例項，而且自行例項化並向整個系統提供這個例項單例模式。單例模式只應在有真正的“單一例項”

的需求時才可使用。

注：全域性變數和單例模式的區分

全域性變數是對一個物件的靜態引用，全域性變數確實可以提供單例模式實現的全域性訪問這個功能，但是它並不能保證應用程式中只有一個例項，同時在編碼規範中，也應該明確指出應該要少用全域性變數，因為過多地使用全域性變數，會造成程式碼難讀，還有就是全域性變數也不能實現繼承（雖然單例模式在繼承上也不能很好地處理，但是還是可以實現繼承的）。而單例模式，其在類中儲存了它的唯一例項，這個類可以保證只能建立一個例項，同時它還提供了一個訪問該唯一例項的全域性訪問點。

使用單例模式，一般需要注意單例模式是用來實現在整個程式中只有一個例項的。單例類的建構函式必須為私有，同時單例類必須提供一個全域性訪問點（使用static 或友元）。

2工廠模式

工廠模式專門負責例項化有大量公共介面的類。

優點：工廠模式可以動態地去決定將哪一個類例項化，而不必事先知道每次要例項化哪一個類。客戶類和工廠類是分開的。消費者無論什麼時候需要某種產品，需要做的只是向工廠提出請求即可。消費者無需修改就可以接納新產品。

缺點：當產品修改時，工廠類也要做相應的修改。

工廠模式包含以下3中形態：

1)簡單工廠(Simple Factory)模式：簡單工廠模式的工廠類是根據提供給它的引數，返回的是幾個可能產品中的一個類的例項，通常情況下它返回的類都有一個公共的父類和公共的方法。

2)工廠方法(Factory Method)模式：工廠方法模式是類的建立模式，其用意是定義一個用於建立產品物件的工廠的介面，而將實際建立工作推遲到工廠介面的子類中。它屬於簡單工廠模式的進一步抽象和推廣。多型的使用，使得工廠方法模式保持了簡單工廠模式的優點，克服了它的缺點。

3)抽象工廠(Abstract Factory)模式：抽象工廠模式是所有形態的工廠模式中最為抽象和最具一般性的一種形態。抽象工廠模式是指當有多個抽象角色時使用的一種工廠模式，抽象工廠模式可以向客戶端提供一個介面，使客戶端在不必指定產品的具體的情況下，建立多個產品族中的產品物件。根據LSP原則(Liskov替換原則)，任何接受父型別的地方，都應當能夠接受子型別。因此，實際上系統所需要的，僅僅是型別與這些抽象產品的具體子類的例項。工廠類負責建立抽象產品的具體子類的例項。

3介面卡模式

概念：介面卡模式也被稱為變壓器模式，它是把一個類的介面轉換成客戶端所期望的另一種介面，從而使原本因介面不匹配而無法一起工作的兩個類能夠一起工作。介面卡類可以根據所傳遞的引數返回一個合適的例項給客戶端。

用途：介面卡模式主要應用於“希望複用一些現存的類，但是介面又與複用環境要求不一致的情況”，在遺留程式碼複用、類庫遷移等方面非常有用。

形式：介面卡模式有物件介面卡和類介面卡2種形式的實現結構。類介面卡採用“多繼承”的實現方式，會引起程式的高耦合，不推薦使用；而物件介面卡採用“物件組合”的方式耦合度低，應用範圍更廣。

事例：現在系統裡已經實現了點、線、正方形，而現在客戶要求實現一個圓形，一般的做法是建立一個Circle類來繼承以後的Shape類，然後去實現對應的display、fill、undisplay方法。此時如果發現專案組其他人已經實現了一個畫圓的類，但是他的方法名卻與自己的不一樣：displayhh、fillhh、undisplayhh,我們不能直接使用這個類，因為那樣無法保證多型。而有的時候也不能要求元件類改寫方法名，此時可以採用介面卡模式。

4享元模式

享元模式以共享的方式高效地支援大量的細粒度物件。享元模式能做到共享的關鍵是區分內蘊狀態和外蘊狀態。將可以共享和不可以共享的狀態從常規類中區分開來，將不可以共享的狀態從類裡剔除出去。客戶端不可以直接建立被共享的物件，而應當使用一個工廠物件負責建立被共享的物件。享元模式大幅度地降低記憶體中物件的數量。

內蘊狀態：儲存在享元內部，不會隨環境的改變而有所不同。

外蘊狀態：隨著環境的改變而改變的，外蘊狀態不能影響內蘊狀態，他們是相互獨立的。

5觀察者模式

概念：觀察者模式(釋出/訂閱模式)提供了避免元件之間緊密耦合的另一種方法，它將觀察者和被觀察者的物件分離開。在該模式中，一個物件通過新增一個方法(該方法允許另一個物件，即觀察者註冊自己)使本身變得可觀察。當可觀察的物件更改時，它會將訊息傳送到已註冊的觀察者。這些觀察者使用該資訊執行的操作與可觀察的物件無關，結果是物件可以相互對話，而不必瞭解原因。Java和C#的事件處理機制就是採用的此種設計模式。

事例：使用者介面可以作為一個觀察者，業務資料是被觀察者，使用者介面觀察業務資料的變化，發現數據變化後，就顯示在介面上。面向物件設計的一個原則是：系統中的每個類將重點放在某一個功能上，而不是其他方面。一個物件只做一件事情，並且將它做好。觀察者模式在模組之間劃定了清晰的界限，提高了應用程式的可維護性和重用性。