在簡單工廠模式中講到簡單工廠模式的缺點，有一點是——簡單工廠模式系統難以擴充套件，一旦新增新產品就不得不修改簡單工廠方法，這樣就會造成簡單工廠的實現邏輯過於複雜，工廠方法模式可以解決簡單工廠模式中存在的這個問題，下面就具體看看工廠模式是如何解決該問題的。
工廠方法模式之所以可以解決簡單工廠的模式，是因為它的實現把具體產品的建立推遲到子類中，此時工廠類不再負責所有產品的建立，而只是給出具體工廠必須實現的介面，這樣工廠方法模式就可以允許系統不修改工廠類邏輯的情況下來新增新產品，這樣也就克服了簡單工廠模式中缺點。下面看下工廠模式的具體實現**（這裡還是以簡單工廠模式中計算器的例子來實現）：
（一）具體類運算操作的介面
namespace（二）運算大工廠介面宣告乙個運算工廠的介面，型別為具體運算類的介面，所有具體的運算介面都繼承與此，方法為創造運算的具體例項抽象工廠方法
}
namespace（三）建立加法運算工廠建立加法運算工廠，建立具體的加法運算例項抽象工廠方法
}
namespace（四）開始我們的加法運算類我們建乙個類，為加法操作的類，繼承與具體類運算的介面，返回乙個具體的值抽象工廠方法}}
namespace（五）開始享用我們的工廠的產品在客戶端例項化乙個加法工廠，我們在加法工廠中建立加法物件，呼叫我們應有的加法方法，進行計算抽象工廠方法}}
namespace使用工廠方法實現的系統，如果系統需要新增新產品時，我們可以利用多型性來完成系統的擴充套件，對於抽象工廠類（建立具體例項的工廠）和具體工廠（具體的運算工廠）中的**都不需要做任何改動。例如，我們加乙個減法的運算，此時我們只需要定義乙個減法具體工廠類和減法類就可以。而不用像簡單工廠模式中那樣去修改工廠類中的實現（具體指新增case語句)。抽象工廠方法}}
講解完工廠模式的具體實現之後，讓我們看下工廠模式中各類之間的uml圖：
從uml圖可以看出，在工廠方法模式中，工廠類與具體產品類具有平行的等級結構，它們之間是一一對應的。針對uml圖的解釋如下：
ifactory介面：充當介面工廠角色，任何具體工廠都必須繼承該介面
addfactory
：充當具體工廠角色，用來建立具體產品
ioperation：充當抽象產品角色，具體產品的介面。任何具體產品都應該繼承該類
addoperation類
：充當具體產品角色，實現抽象產品介面中獲取結果值的方法，由具體工廠類建立，它們之間有一一對應的關係。
工廠方法模式與簡單工廠模式再結構上的不同不是很明顯。工廠方法類的核心是乙個抽象（介面也可以）工廠類，而簡單工廠模式把核心放在乙個具體類上。
工廠方法模式之所以有乙個別名叫多型性工廠模式是因為具體工廠類都有共同的介面，或者有共同的抽象父類（多型性）。
當系統擴充套件需要新增新的產品物件時，僅僅需要新增乙個具體物件以及乙個具體工廠物件，原有工廠物件不需要進行任何修改，也不需要修改客戶端，很好的符合了"開放－封閉"原則。而簡單工廠模式在新增新產品物件後不得不修改工廠方法，擴充套件性不好。
工廠方法模式退化後可以演變成簡單工廠模式。
設計模式 工廠模式之工廠方法模式
工廠方法模式是指定義乙個建立物件的介面，然後實現這個介面的工廠來決定建立什麼樣的例項。工廠方法讓類的例項推遲到子類中進行。在這個模式中，只關心需要建立的是什麼工廠，不需要關心建立的細節。而且新加入的產品符合開閉原則。1 建立支付介面，裡面定義抽象的支付方法。package com.gupao.vip...
設計模式之工廠方法模式
package com.csair.design.pattern 工廠方法，有抽象基類，每個子類生產乙個具體物件，與抽象工廠的關係是，抽象工廠生產多個產品 產品有某種內在聯絡 工廠方法只生產乙個物件 author ppt public class factorymethod public stati...
設計模式之工廠方法模式
在介紹工廠方法模式之前，先來介紹一下簡單工廠。什麼是簡單工廠？在類中，難免要例項化一些類，那麼我們把這些類的例項化抽離出來封裝成乙個工廠類，工廠類提供乙個公共的靜態或非靜態的方法來返回其他物件所需要的物件。這樣做的目的就是將物件的例項化與邏輯 分開，提高 的復用能力。這就是簡單工廠。public a...