先看各自的結構：
簡單工廠模式（SimpleFactory Mode）：
Key值給傳回一個相對應的算法的實體。
優點：
友善擴充算法，比如增加一個開根号的功能，我們隻要繼續繼承運算類就行了，同時用戶端也就是使用者不知道具體的實作細節，隻要給出相關标示符，工廠函數就馬上給他建立一個他想要的實體就行了。減少了使用者和功能開發者之間的耦合度。
缺點：
Switch，這樣便破壞了OCP，而且當有多級結構繼承的時候，簡單工廠就會因為隻能對應平行一層記得繼承，不得不使得好多類繼承同一個接口，然後得到A*B這麼多的工廠實體可能，工廠函數很難維護。
工廠方法模式（Factory Method）：
定義一個用于建立對象的接口，讓子類決定執行個體化哪一個類。工廠方法使一個類的執行個體化延遲到其子類。
優點：
switch的情況，也就不存在擴充不滿足OCP的這個問題。
缺點：
PC，分為多個系統，那麼我們可以把所有的系統都抽象出來（類似上面的加減乘除），然後我們在抽象出來工廠，但是如果這個時候我們有兩個硬體呢，PC和Phone，雖然我們可以保證隻有這兩個硬體了，但是如果用基本的抽象工廠去實作的話還是很别扭。
抽象工廠模式（Abstract Factory）：
提供一個建立一系列相關或者互相依賴對象的接口，而無需指定它們具體的類。
優點：
OCP的，而且可以滿足産品切換，能實作的前提是比如A和B兩個産品，它們有1和2兩個方法接口（類），現在我們在增加新的産品C（假設也是隻有1和2兩個方法接口），我們要做的隻是增加一個産品類再增加一個工廠類就行了，如果是簡單工廠或者是工廠方法的的話通常都是增加兩個算法類C.1,C.2，簡單工廠需要修改switch增加兩個語句，工廠方法是在增加兩個工廠類。可見抽象工廠的優點。
缺點：
顯而易見，太重了。
對比：
OCP，不滿足OCP的代價就是難維護，在維護的時候容易引發新的BUG，相比之下，工廠方法則是把對象的執行個體化延遲到了繼承的子類裡面，這樣可以量或的擴充工廠。擴充的是時候滿足OCP，但是不支援産品切換，也就是隻能滿足一層的産品（算法）抽象，而抽象工廠則是繼續把産品進行再次抽象，最後得到一個可以支援産品切換的結構，但問題是太重了，過于複雜，不過還好，很多支援反射的語言，我們可以直接通過反射技術來優化這個“過重”的缺點。當然，也可以用反射來優化前面兩個工廠結構（但是抽象工廠和工廠方法相比，兩者也都隻是支援一個地方的可擴充而已，不要誤解為抽象工廠可以擴充兩個地方）。
進化：
OCP ； 優化滿足産品切換
簡單工廠 ---------------------------> 工廠方法 -------------------------------->
抽象工廠
退化：
增加了和用戶端之間的耦合度（用戶端需要知道各種工廠）；變得太重了
簡單工廠 ---------------------------> 工廠方法 -------------------------------->
抽象工廠