設計模式之工廠方法模式（Factory Method)

 今天來介紹工廠方法模式，工廠方法（Factory Method）模式的意義在于定義一個建立工廠類的一個抽象工廠類（接口），具體的工廠類都實作這個抽象的工廠類，這裡定義成接口，也就是所有具體的工廠實作類都要實作這個抽象的工廠類，之後再定義一個實際需求當中需要被建立的的對象的父類，此處這個父類也定義成接口。

工廠方法模式的對簡單工廠模式進行了抽象。有一個抽象的Factory類（可以是抽象類和接口），這個類将不在負責具體的産品生産，而是隻制定一些規範，具體的生産工作由其子類去完成。在這個模式中，工廠類和産品類往往可以依次對應。即一個抽象工廠對應一個抽象産品，一個具體工廠對應一個具體産品，這個具體的工廠就負責生産對應的産品。

如果閑介紹的墨迹直接看紅色部分

類圖如下：

抽象工廠(Creator)角色：是工廠方法模式的核心，與應用程式無關。任何在模式中建立的對象的工廠類必須實作這個接口。　　具體工廠(Concrete Creator)角色：這是實作抽象工廠接口的具體工廠類，包含與應用程式密切相關的邏輯，并且受到應用程式調用以建立産品對象。在上圖中有兩個這樣的角色：BulbCreator與TubeCreator。　　抽象産品(Product)角色：工廠方法模式所建立的對象的超類型，也就是産品對象的共同父類或共同擁有的接口。在上圖中，這個角色是Light。

　　具體産品(Concrete Product)角色：這個角色實作了抽象産品角色所定義的接口。某具體産品有專門的具體工廠建立，它們之間往往一一對應。

執行個體代碼如下：

抽象工廠

package com.pattern.FactoryMethod;

public interface Creator {

/**

* 工廠方法

*/

public Product factory();

}

抽象産品

public interface Product {

具體工廠1

public class ConcreteCreator1 implements Creator {

public Product factory() {

return new ConcreteProduct1();

具體工廠2

public class ConcreteCreator2 implements Creator {

return new ConcreteProduct2();

實際産品1

public class ConcreteProduct1 implements Product{

public ConcreteProduct1() {

// do something

實際産品2

用戶端

public class Client {

private static Creator creator1,creator2;

private static Product prod1,prod2;

* @param args

public static void main(String[] args) {

creator1 = new ConcreteCreator1();

prod1 = creator1.factory();

creator2 = new ConcreteCreator2();

prod2 = creator2.factory();

白話文，再白話一遍工廠方法模式

接上文的簡單工廠，以 張三、李四、王五 球類比賽為例

想在是踢足球踢的好的不隻張三一個人了，有好多個張三踢的都好，并且組成了一個牛逼的隊伍，有好多個類似張三的人，同理，足球、籃球也都一樣，都出現了好多牛逼的人，這時候學校就不能單方面的指派他們中的某一個人代表學校去參加比賽，這時候就需要沒中球有個專門的管理人員由每種球類的管理者來挑選他們這個牛逼的隊伍中誰來應對這場意義深刻的比賽，不難看出，這時候管理者代表的意義就為具體的工廠類，負責造具體的球員，當然球員不是他造的是他來選的，這時候就會有3個管理者，即三個具體的工廠類，而球員呢有一個共性，就是都為學生，都為某牛逼學校的學生，是以這些學生就相當與了産品，這樣當要出去比賽時候，學校就會委派特定的管理者進行挑選牛逼人參賽，代碼跟上面的差不多，套用即可，當有需要籃球對決的時候，籃球管理者就出來挑選自己的愛将出陣。

工廠方法模式優缺點：

優點：

多态性：客戶代碼可以做到與特定應用無關，适用于任何實體類

子類可以重新新的實作，也可以繼承父類的實作。加一層間接性，增加了靈活性。

良好的封裝性，代碼結構清晰。擴充性好，在增加産品類的情況下，隻需要适當修改具體的工廠類或擴充一個工廠類，就可“擁抱變化”屏蔽産品類。産品類的實作如何變化，調用者不需要關心，隻需要關心産品的接口，隻要接口保持不變，系統的上層子產品就不會發生變化。

耦合度低，高層子產品隻需要知道産品的抽象類，其他的實作都不需要關心。

缺點：需要Creator和相應的子類作為工廠方法的載體，如果應用模型确實需要creator和子類的存在，則很好，反之需要增加一個類的層次。