單例設計模式

單例設計模式就是保證一個類中，有且只有一個例項存在並提供一個訪問點供全域性訪問，該例項可以被所有的程式來訪問。

一般在這種情況下用：

• 當要用一個類時，又要用該類中的一個例項；
• new 來建立例項時會給程式造成資源的浪費，而且例項越多也不好控制。
• 不同的執行緒呼叫時，可能會引起不同步的現象。

實際開發中用到單例模式的情況：

• 資料庫連線池
• Windows的Task Manager（工作管理員），打不開第二個工作管理員
• 大部分的音樂播放器
• 網站的計數器
• windows的Recycle Bin（回收站）也是典型的單例應用。在整個系統執行過程中，回收站一直維護著僅有的一個例項。

工廠設計模式

首先，工廠方法模式是new一個物件的替代品，所以在所有需要生成物件的地方都可以使用，但是需要慎重地考慮是否要增加一個工廠類進行管理，增加程式碼的複雜度。

其次，需要靈活的、可擴充套件的框架時，可以考慮採用工廠方法模式。萬物皆物件，那萬物也就皆產品類，例如需要設計一個連線郵件伺服器的框架，有三種網路協議可供選擇：POP3、IMAP、HTTP，我們就可以把這三種連線方法作為產品類，定義一個介面如IConnectMail，然後定義對郵件的操作方法，三個具體的產品類（也就是連線方式）進行不同的實現，再定義一個工廠方法，按照不同的傳入條件，選擇不同的連線方式。如此設計，可以做到完美的擴充套件，如某些郵件伺服器提供了WebService介面，很好，我們只要增加一個產品類就可以了。

再次，工廠方法模式可以用在異構專案中，例如通過WebService與一個非Java的專案互動，雖然WebService號稱是可以做到異構系統的同構化，但是在實際的開發中，還是會碰到很多問題，如型別問題、WSDL檔案的支援問題，等等，從WSDL中產生的物件都認為是一個產品，然後由一個具體的工廠類進行管理，減少與外圍系統的耦合。

最後，可以使用在測試驅動開發的框架下，例如，測試一個類A，就需要把與類A有關聯關係的類B也同時產生出來，我們可以使用工廠方法模式把類B虛擬出來，避免類A與類B的耦合。目前由於JMock和EasyMock的誕生，該使用場景已經弱化了，讀者可以在遇到此種情況時直接考慮使用JMock或EasyMock。
 

代理設計模式

介面卡模式