1、為什麼要使用工廠模式？
首先先看看不使用工廠模式的**
class myapi
;class a : public myapi
};class b : public myapi
};void clientfunc()
在物件導向程式設計裡面，非常講究層的劃分和模組的劃分。通常按照三層來劃分程式，分別是表現層、邏輯層和資料層，它們之間都要通過介面來通訊。在每乙個層裡面，又有 很多個小模組，每個小模組對外則是乙個整體，所以乙個模組對外應該提供介面，其他地方需要使用到這個模組的功能時，可以通過此介面來進行呼叫。 這也就是常說的「介面是 被其隔離部分的外觀」。
有何問題？請各位仔細看客戶端這段話：
myapi * a = new a;
myapi * b = new b;
然後再想想介面的功能和思想，發現什麼了？仔細再想想？你會發現在客戶端呼叫的時候，客戶端不但知道了介面，同時還知道了具體的實現就是a。 介面的思想是「封裝 隔離」，而實現類a/b應該是被介面myapi封裝並同客戶端隔離開的，也就是說，客戶端根本就不應該知道具體的實現類是a/b。有朋友說，那好，我就把a/b從客戶端拿掉，讓api真正地對 實現進行「封裝 隔離」。可是，新的問題出現了，當他把「 new a（）」去掉後，卻發現無法得到myapi介面物件了，怎麼辦呢？把這個問題描述一下：在物件導向程式設計中，出現只知介面而不知實現，該怎麼辦？ 就像現在的client，它知道要使用api介面，但是不知由誰實現，也不知道如何實現，從而得不到介面物件，就無法使用介面，該怎麼辦呢？
2、解決方案--是工廠模式：
請看以下**：
class myapi
;class a : public myapi
};class b : public myapi
};class factory
else if (1 == type)
else
}};void clientfunc()
就如同上面的示例 ，客戶端通過簡單工廠建立了乙個實現介面的物件 ，然後面向介面程式設計 ，從客戶端來看 ，它根本不知道具體的實現是什麼 ，也不知道是如何實現的 ，它只知道通過工廠獲得了乙個介面物件 ，然後通過這個介面來獲取想要的功能 。事實上 ，簡單工廠能幫助我們真正地開始面向介面程式設計 ，像以前的做法 ，其實只是用到了介面的多型部分的功能 ，而最重要的 「封裝隔離性 」並沒有體現出來。
3、常見問題：
首先來解決乙個常見的問題 ：可能有朋友會認為 ，上面示例中的簡單工廠看起來不就是把客戶端裡面的 「new a / new b」移動到簡單工廠裡面嗎 ？不還是一樣通過new乙個實現類來得到介面嗎？把 「new a / new b」這句話放到客戶端和放到簡單工廠裡面有什麼不同嗎 ？提示理解這個問題的重點就在於理解簡單工廠所處的位置 。根據前面的學習 ，我們知道介面是用來封裝隔離具體的實現的 ，目標就是不要讓客戶端知道封裝體內部的具體實現 。簡單工廠的位置是位於封裝體內的 ，也就是簡單工廠是跟介面和具體的實現在一起的 ，算是封裝體內部的乙個類 ，所以簡單工廠知道具體的實現類是沒有關係的 。
4、工廠模式的優缺點
簡單工廠有以下優點 :
■幫助封裝簡單工廠雖然很簡單 ，但是非常友好地幫助我們實現了元件的封裝 ，然後讓元件外部能真正面向介面程式設計 。
■解耦通過簡單工廠 ，實現了客戶端和具體實現類的解耦 。如同上面的例子 ，客戶端根本就不知道具體是由誰來實現 ，也不知道具體是如何實現的 ，客戶端只是通過工廠獲取它需要的介面物件 。
簡單工廠有以下缺點 :
■可能增加客戶端的複雜度如果通過客戶端的引數來選擇具體的實現類 ，那麼就必須讓客戶端能理解各個引數所代表的具體功能和含義,各個引數所代表的具體功能和含義 ，這樣會增加客戶端使用的難度 ，也部分暴露了內部實現 ，這種情況可以選用可配置的方式來實現 。
■不方便擴充套件子工廠私有化簡單工廠的構造方法 ，使用靜態方法來建立介面 ，也就不能通過寫簡單工廠類的子類來改變建立介面的方法的行為了 。不過 ，通常情況下是不需要為簡單工廠建立子類的 。
陳臣 (2011-01-01). 研磨設計模式 (kindle locations 856-860). 清華大學出版社. kindle edition.
Design Pattern 工廠模式
當有一些要例項化的具體類，究竟例項化哪個類，要在執行時由一些條件來決定。當 使用大量具體類時，我們就要考慮使用工廠模式了。定義了乙個建立物件的介面，但由子類決定要例項化的類是哪乙個。工廠方法讓類把例項化推遲到子類。public abstract class pizzastore protected ...
design pattern 外觀模式
針對問題 在軟體開發系統中，客戶程式經常會與複雜系統的內部子系統之間產生耦合，而導致客戶程式隨著子系統的變化而變化。那麼如何簡化客戶程式與子系統之間的互動介面？如何將複雜系統的內部子系統與客戶程式之間的依賴解耦？為子系統中的一組介面提供乙個一致的介面，facade 模式定義了乙個高層介面，這個介面使...
design pattern 狀態模式
針對問題 有時候乙個方法可能有很多if.else來判斷狀態後再執行相關操作，當很多方法都重複的出現這樣的if.else判斷時，就可以考慮用狀態模式了。狀態模式的結構圖和策略模式一樣，事實上狀態模式和策略很相似，不同的是狀態模式除了委託狀態外，狀態實體自身持有主實體物件的引用，在狀態實體內部可以動態的...