【設計模式】工廠模式（靜態工廠模式、工廠方法模式、抽象工廠模式）

時間 2019-11-06

原文原文鏈接

引子

話說十年前，有一個暴發戶，他家有三輛汽車——Benz 奔馳、Bmw 寶馬、Audi 奧迪，還僱了司機爲他開車。不過，暴發戶坐車時老是怪怪的： Benz 車後跟司機說「開奔馳車！上」，坐上 Bmw 後他說「開寶馬車！」，坐上 Audi 說「開奧迪車！」。你必定說：這人有病！直接說開車不就好了？！html

而當把這個暴發戶的行爲放到咱們程序設計中來時，會發現這是一個廣泛存在的現象。java

幸運的是，這種有病的現象在 OO（面向對象）語言中能夠避免了。設計模式

下面就以 Java 語言爲基礎來引入咱們的主題：工廠模式。ide

工廠模式主要是爲建立對象提供過渡接口，以便將建立對象的具體過程屏蔽隔離起來，達到提升靈活性的目的。spa

工廠模式在《Java 與模式》中分爲三類：

簡單工廠模式（Simple Factory）
工廠方法模式（Factory Method）
抽象工廠模式（Abstract Factory）

這三種模式從上到下逐步抽象，而且更具通常性。

GOF 在《設計模式》一書中將工廠模式分爲兩類：工廠方法模式（Factory Method）與抽象工廠模式（Abstract Factory）。將簡單工廠模式（Simple Factory）看爲工廠方法模式的一種特例，二者歸爲一類。

下面來看看這些工廠模式是怎麼來「治病」的。

簡單工廠模式

簡單工廠模式又稱靜態工廠方法模式。

重命名上就能夠看出這個模式必定很簡單。它存在的目的很簡單： 定義一個用於建立對象的接口 。

先來看看它的組成：

工廠類角色：這是本模式的核心，含有必定的商業邏輯和判斷邏輯。在java中它每每由一個具體類實現。
抽象產品角色：它通常是具體產品繼承的父類或者實現的接口。在java中由接口或者抽象類來實現。
具體產品角色：工廠類所建立的對象就是此角色的實例。在java中由一個具體類實現。用類圖來清晰的表示下的它們之間的關係

那麼簡單工廠模式怎麼來使用呢？設計

咱們就以簡單工廠模式來改造暴發戶坐車的方式——如今暴發戶只須要坐在車裏對司機說句：「開車」就能夠了code

//抽象產品角色
public interface Car{
    public void drive();
}

//具體產品角色
public class Benz implements Car{
    public void drive() {
          System.out.println("Driving Benz ");
    }
}
public class Bmw implements Car{
    public void drive() {
          System.out.println("Driving Bmw ");
    }
}

//工廠類角色
public class Driver{
    //工廠方法.注意 返回類型爲抽象產品角色
    public static Car driverCar(String s)throws Exception{
        //判斷邏輯，返回具體的產品角色給 Client
         if(s.equalsIgnoreCase("Benz"))
               return new Benz();
         else if(s.equalsIgnoreCase("Bmw"))
               return new Bmw();
                ......
         else throw new Exception();
        。。。
    }
}

//歡迎暴發戶出場......
public class Magnate{
    public static void main(String[] args){
       try{
           //告訴司機我今天坐奔馳
           Car car = Driver.driverCar("benz");
           //下命令：開車
           car.drive();
           。。。
        }
    }
}

View Code

　　將本程序空缺的其餘信息填充完整後便可運行。htm

　　程序中各個類的關係表達以下：對象

　　這即是簡單工廠模式了。blog

　　那麼它帶來了什麼好處呢？

首先，使用了簡單工廠模式後，咱們的程序不在「有病」，更加符合現實中的狀況；
並且客戶端免除了直接建立產品對象的責任，而僅僅負責「消費」產品（正如暴發戶所爲）

　　下面咱們從開閉原則（對擴展開放；對修改封閉）上來分析下簡單工廠模式。

當暴發戶增長了一輛車的時候，只要符合抽象產品制定的合同，那麼只要通知工廠類知道就能夠被客戶使用了。因此對產品部分來講，它是符合開閉原則的；
可是工廠部分好像不太理想，由於每增長一輛車，都要在工廠類中增長相應的業務邏輯或者判斷邏輯，這顯然是違背開閉原則的。
可想而知對於新產品的加入，工廠類是很被動的。對於這樣的工廠類（例子中是爲司機師傅），咱們稱它爲全能類或者上帝類。

　　在實際應用中，極可能產品是一個多層次的樹狀結構。
　　因爲簡單工廠模式中只有一個工廠類來對應這些產品，因此這可能會把咱們的上帝累壞了，因而工廠方法模式做爲救世主出現了。

工廠方法模式

　　工廠方法模式去掉了簡單工廠模式中工廠方法的靜態屬性，使得它能夠被子類繼承。這樣在簡單工廠模式裏集中在工廠方法上的壓力能夠由工廠方法模式裏不一樣的工廠子類來分擔。
　　工廠方法模式的結構，來看下它的組成：

抽象工廠角色：這是工廠方法模式的核心，它與應用程序無關。是具體工廠角色必須實現的接口或者必須繼承的父類。在 java 中它由抽象類或者接口來實現。
具體工廠角色：它含有和具體業務邏輯有關的代碼。由應用程序調用以建立對應的具體產品的對象。
抽象產品角色：它是具體產品繼承的父類或者是實現的接口。在 java 中通常有抽象類或者接口來實現。
具體產品角色：具體工廠角色所建立的對象就是此角色的實例。在 java 中由具體的類來實現。

　　用類圖來清晰的表示下的它們之間的關係：

　　工廠方法模式使用繼承自抽象工廠角色的多個子類來代替簡單工廠模式中的「上帝類」。

　　正如上面所說，這樣便分擔了對象承受的壓力；並且這樣使得結構變得靈活起來——當有新的產品（即暴發戶的汽車）產生時，只要按照抽象產品角色、抽象工廠角色提供的合同來生成，那麼就能夠被客戶使用，而沒必要去修改任何已有的代碼。能夠看出工廠角色的結構也是符合開閉原則的！

　　來看看工廠方法模式各個角色之間是如何來協調的。
　　話說暴發戶生意越作越大，本身的愛車也愈來愈多。這可苦了那位司機師傅了，什麼車它都要記得，維護，都要通過他來使用！因而暴發戶同情他說：看你跟我這麼多年的份上，之後你不用這麼辛苦了，我給你分配幾我的手，你只管管好他們就好了！因而，工廠方法模式的管理出現了。

//抽象產品角色，具體產品角色與簡單工廠模式相似，只是變得複雜了些，略。
//抽象工廠角色
public interface Driver{
    public Car driverCar();
}
public class BenzDriver implements Driver{
    public Car driverCar(){
          return new Benz();
    }
}
public class BmwDriver implements Driver{
    public Car driverCar() {
          return new Bmw();
    }
}
//應該和具體產品造成對應關係...

//有請暴發戶先生
public class Magnate

{
    public static void main(String[] args)
    {
        try{
              Driver driver = new BenzDriver();
              Car car = driver.driverCar();
              car.drive();
        }
    ……
}

View Code

　　能夠看出工廠方法的加入，使得對象的數量成倍增加。

　　當產品種類很是多時，會出現大量的與之對應的工廠對象，這不是咱們所但願的。

　　由於若是不能避免這種狀況，能夠考慮使用簡單工廠模式與工廠方法模式相結合的方式來減小工廠類：即對於產品樹上相似的種類（通常是樹的葉子中互爲兄弟的）使用簡單工廠模式來實現。

小結

　　工廠方法模式彷彿已經很完美的對對象的建立進行了包裝，使得客戶程序中僅僅處理抽象產品角色提供的接口。

　　那咱們是否必定要在代碼中遍及工廠呢？大可沒必要。也許在下面狀況下你能夠考慮使用工廠方法模式：

當客戶程序不須要知道要使用對象的建立過程。
客戶程序使用的對象存在變更的可能，或者根本就不知道使用哪個具體的對象。

　　簡單工廠模式與工廠方法模式真正的避免了代碼的改動了？沒有。

在簡單工廠模式中，新產品的加入要修改工廠角色中的判斷語句；
而在工廠方法模式中，要麼將判斷邏輯留在抽象工廠角色中，要麼在客戶程序中將具體工廠角色寫死。並且產品對象建立條件的改變必然會引發工廠角色的修改。面對這種狀況，Java 的反射機制與配置文件的巧妙結合突破了限制——這在 Spring 中完美的體現了出來。