定義：工廠方法(factory method)模式的意義是定義乙個建立產品工廠介面，將實際建立工作推遲到子類當中。核心工廠類不再負責產品的建立，僅負責具體工廠子類必須實現的介面，這樣進一步抽象化的好處是使得工廠方法模式可以使系統在不修改具體工廠角色的情況下引進新的產品。
就是說原來簡單工廠設計模式產品的建立必須要核心的乙個工廠類來完成，現在把工廠類定義成乙個介面，根據產品的需要我們建立具體的工廠類來繼承這個核心工廠類，讓具體的工廠類來建立產品。這樣在要增加新的產品的時候我們只需要增加工廠類而不是改變工廠類。符合開閉原則。
1.仍然具有簡單工廠的優點，伺服器端修改了具體產品的類名以後，客戶端不知道。
2.當客戶端需要擴充套件乙個新的產品，不需要修改作者原來的**，只是擴充套件乙個新的工廠而已，符合開閉原則。
每加乙個產品，就需要加乙個產品工廠的類，增加了額外的開發量,如果產品的種類過多就會導致工廠類的數量龐大。
工廠方法克服了簡單工廠違背開放-封閉原則的缺點，又保持了封裝物件建立過程的優點。它們都是集中封裝了物件的建立，在物件時，不需要做大的改動就可實現，降低了客戶程式與產品物件的耦合。工廠方法模式是簡單工廠模式的進一步抽象和推廣。由於使用了多型性，工廠方法模式保持了簡單工廠模式的優點，而且克服了它的缺點。但缺點是由於每加乙個產品，就需要加乙個產品工廠的類，增加了額外的開發量,如果產品的種類過多就會導致工廠類的數量龐大。
package designpattern.com.design.factorymethod;
public
class
demo1
}//首先兩個抽象類，乙個工廠抽象類，乙個是食物抽象類，每乙個工廠抽象類對應為乙個或一種食物類服務
abstract
class
foodfactory
abstract
class
food
class
ricefactory
extends
foodfactory
// 建立具體的工廠類
}class
rice
extends
food
}
還有兩個問題
問題1：
簡單工廠，工廠方法都有乙個優點，就是伺服器端的具體產品類名變化了以後，客戶端不知道，但是，看我們現在的**，客戶端仍然依賴於具體的工廠的類名，如果伺服器端修改累具體的類名，又回到最初的起點。
解釋：工廠的名字，可以看做介面，對於介面作者有責任有義務，保證工廠的名字是穩定的，也就是說，雖然客戶端依賴於工廠的具體的類名，可是所有的工廠名字都趨於穩定（不是百分百不變）至少工廠類的名字，要比具體產品的名字更加穩定，我們原來在原來產品的基礎上在包裝一層工廠就是希望變化發生在工廠內部（產品），而工廠本身對外提供的介面是不變的。
問題2：
既然新增的類是客戶端自己新增的，為什麼還要借助於工廠，不自己例項化呢。
解釋：產品的一些功能的實現是需要依賴於工廠類的，就是說可能原來作者實現的關於food類的方法是需要產品先被工廠包裝再作為引數傳入方法中，如果我們自己例項化這個類那麼在呼叫對應方法的時候回導致傳入的引數型別不匹配。
設計模式（1） 工廠方法模式
工廠方法模式uml類圖如圖所示 說明 具體產品繼承抽象產品，具體工廠繼承抽象工廠，具體工廠依賴具體產品。具體例項 如下所示 其實是在簡單工廠模式例項 的基礎上對工廠類進行了一下抽象 抽象工廠類 public abstract class abstractfactory具體產品a工廠類 ublic c...
設計模式 1 工廠方法模式
簡單工廠模式有個問題是，類的建立是需要依賴工廠類的，如果要拓展程式，那麼需要對工廠類進行修改，這個增加了風險。工廠方法模式可以避免這種情況，方法建立乙個工廠介面和建立多個工廠類，理解如下 對了抽象方法a，b和c分別為其的兩個不同實現，現在建立工廠介面d，工廠介面d的實列類e和f分別對b和c進行實列化...
設計模式1 工廠方法模式
關於工廠的設計模式，我們可以列出來這三個，既然是都和工廠有關，當然就少不了他們的比較，這裡簡單說下，在比較中理解以便更好的學習。本篇著重講工廠方法模式。簡單工廠模式不屬於23種經典設計模式的一種，是乙個專門生產某個產品的類，例如 乙個鍵盤工廠，不管生產什麼牌子的鍵盤，就只能生產鍵盤，對鍵盤的邏輯操作...