先看各自的結構：

簡單工廠模式（SimpleFactory Mode）：

    簡單工廠模式的思路是，首先我們把一些共性的東西（演算法）拿出來，進行抽象，比如加減乘除。然後我們在定義一個類作為工廠類，工廠類的作用就是根據傳過來的字串或者其他Key值給返回一個相對應的演算法的實體。

優點：

    方便擴充套件演算法，比如增加一個開根號的功能，我們只要繼續繼承運算類就行了，同時客戶端也就是使用者不知道具體的實現細節，只要給出相關標示符，工廠函式就馬上給他建立一個他想要的實體就行了。減少了使用者和功能開發者之間的耦合度。

缺點：

    比較明顯，在進行擴充套件的時候，我們要更改工廠函式裡面的那個分支語句Switch

工廠方法模式（Factory Method）：

    定義一個用於建立物件的介面，讓子類決定例項化哪一個類。工廠方法使一個類的例項化延遲到其子類。

優點：

    演算法實體的建立被延遲到了工廠子類裡，我們不在工廠裡直接建立物件，而是直接封裝一個一個的小工廠，每個工廠負責建立自己的子類，這樣就不存在switch的情況，也就不存在擴充套件不滿足OCP的這個問題。

缺點：

    如果演算法種類很多，那麼繼承抽象工廠的子類也就會很多，不是很好維護，同時不支援產品切換，比如我們要開發PC

抽象工廠模式（Abstract Factory）：

    提供一個建立一系列相關或者相互依賴物件的介面，而無需指定它們具體的類。

優點：

    首先是滿足OCP的，而且可以滿足產品切換，能實現的前提是比如A和B兩個產品，它們有1和2兩個方法介面（類），現在我們在增加新的產品C（假設也是隻有1和2兩個方法介面），我們要做的只是增加一個產品類再增加一個工廠類就行了，如果是簡單工廠或者是工廠方法的的話通常都是增加兩個演算法類

缺點：

    顯而易見，太重了。

對比：

    簡單工廠實現簡單，擴充套件也很容易，但是不滿足OCP，不滿足OCP的代價就是難維護，在維護的時候容易引發新的BUG，相比之下，工廠方法則是把物件的例項化延遲到了繼承的子類裡面，這樣可以量或的擴充套件工廠。擴充套件的是時候滿足OCP，但是不支援產品切換，也就是隻能滿足一層的產品（演算法）抽象，而抽象工廠則是繼續把產品進行再次抽象，最後得到一個可以支援產品切換的結構，但問題是太重了，過於複雜，不過還好，很多支援反射的語言，我們可以直接通過反射技術來優化這個“過重”的缺點。當然，也可以用反射來優化前面兩個工廠結構（但是抽象工廠和工廠方法相比，兩者也都只是支援一個地方的可擴充套件而已，不要誤解為抽象工廠可以擴充套件兩個地方）。

進化：

            優化滿足OCP        ；        優化滿足產品切換

簡單工廠 --------------------------->  工廠方法  --------------------------------> 抽象工廠

退化：

    增加了和客戶端之間的耦合度（客戶端需要知道各種工廠）；變得太重了                                    

簡單工廠 --------------------------->  工廠方法  --------------------------------> 抽象工廠