引用戀楓的工廠模式基本原理

一、引子 
      話說十年前，有一個暴發戶，他家有三輛汽車——Benz賓士、Bmw寶馬、Audi奧迪，還僱了司機為他開車。不過，暴發戶坐車時總是怪怪的：上Benz車後跟司機說“開賓士車！”，坐上Bmw後他說“開寶馬車！”，坐上Audi說“開奧迪車！”。你一定說：這人有病！直接說開車不就行了？！

      而當把這個暴發戶的行為放到我們程式設計中來時，會發現這是一個普遍存在的現象。幸運的是，這種有病的現象在OO（面向物件）語言中可以避免了。下面就以Java語言為基礎來引入我們本文的主題：工廠模式。

二、分類 
      工廠模式主要是為建立物件提供過渡介面，以便將建立物件的具體過程遮蔽隔離起來，達到提高靈活性的目的。

     工廠模式在《Java與模式》中分為三類：
     1）簡單工廠模式（Simple Factory）

     2）工廠方法模式（Factory Method）

     3）抽象工廠模式（Abstract Factory）

      這三種模式從上到下逐步抽象，並且更具一般性。GOF在《設計模式》一書中將工廠模式分為兩類：工廠方法模式（Factory Method）與抽象工廠模式（Abstract Factory）。將簡單工廠模式（Simple Factory）看為工廠方法模式的一種特例，兩者歸為一類。兩者皆可，在本文使用《Java與模式》的分類方法。下面來看看這些工廠模式是怎麼來“治病”的。

三、簡單工廠模式

     簡單工廠模式又稱靜態工廠方法模式。重新命名上就可以看出這個模式一定很簡單。它存在的目的很簡單：定義一個用於建立物件的介面。

先來看看它的組成：

       1) 工廠類角色：這是本模式的核心，含有一定的商業邏輯和判斷邏輯。在java中它往往由一個具體類實現。

      2) 抽象產品角色：它一般是具體產品繼承的父類或者實現的介面。在java中由介面或者抽象類來實現。

      3) 具體產品角色：工廠類所建立的物件就是此角色的例項。在java中由一個具體類實現。那麼簡單工廠模式怎麼來使用呢？我們就以簡單工廠模式來改造暴發戶坐車的方式——現在暴發戶只需要坐在車裡對司機說句：“開車”就可以了。

package factory.simplefactory;
/**
 *
 *
 * 這是簡單工場模式
 * @author Administrator
 *
 */
public class Magnate_sf{
 public static void main(String[] args) {
  //告訴司機開賓士車
  Car car = Driver.driver("Benz");
  //下命令：開車
  car.drive();
 }
}
//抽象產品角色
interface Car {
 public void drive();
}
//具體產品角色
class Benz implements Car{

 public void drive() {
  System.out.println("今天開賓士車");
 }
 
}
class Bmw implements Car{
 
 public void drive() {
  System.out.println("今天開寶馬車");
 }
 
}
class Audi implements Car{
 
 public void drive() {
  System.out.println("今天開奧迪車");
 }
 
}
//工廠類角色
class Driver{
 //工廠方法，注意返回型別是抽象產品角色
 public static Car driver(String car){
  if("Benz".equalsIgnoreCase(car))
   return new Benz();
  else if("Bmw".equalsIgnoreCase(car))
   return new Bmw();
  else if("Audi".equalsIgnoreCase(car))
   return new Audi();
  return null;
 }
}

       這便是簡單工廠模式了。怎麼樣，使用起來很簡單吧？那麼它帶來了什麼好處呢？ 
       首先，使用了簡單工廠模式後，我們的程式不在“有病”，更加符合現實中的情況；而且客戶端免除了直接建立產品物件的責任，而僅僅負責“消費”產品（正如暴發戶所為）。

       下面我們從開閉原則（對擴充套件開放；對修改封閉）上來分析下簡單工廠模式。當暴發戶增加了一輛車的時候，只要符合抽象產品制定的合同，那麼只要通知工廠類知道就可以被客戶使用了。所以對產品部分來說，它是符合開閉原則的；但是工廠部分好像不太理想，因為每增加一輛車，都要在工廠類中增加相應的業務邏輯或者判斷邏輯，這顯然是違背開閉原則的。可想而知對於新產品的加入，工廠類是很被動的。對於這樣的工廠類（在我們的例子中是為司機師傅），我們稱它為全能類或者上帝類。

      我們舉的例子是最簡單的情況，而在實際應用中，很可能產品是一個多層次的樹狀結構。由於簡單工廠模式中只有一個工廠類來對應這些產品，所以這可能會把我們的上帝累壞了，也累壞了我們這些程式設計師:( 於是工廠方法模式作為救世主出現了。

四、工廠方法模式 

      工廠方法模式去掉了簡單工廠模式中工廠方法的靜態屬性，使得它可以被子類繼承。這樣在簡單工廠模式裡集中在工廠方法上的壓力可以由工廠方法模式裡不同的工廠子類來分。

你應該大致猜出了工廠方法模式的結構，來看下它的組成：

      1)抽象工廠角色： 這是工廠方法模式的核心，它與應用程式無關。是具體工廠角色必須實現的介面或者必須繼承的父類。在java中它由抽象類或者介面來實現。

      2)具體工廠角色：它含有和具體業務邏輯有關的程式碼。由應用程式呼叫以建立對應的具體產品的物件。

     3)抽象產品角色：它是具體產品繼承的父類或者是實現的介面。在java中一般有抽象類或者介面來實現。

     4)具體產品角色：具體工廠角色所建立的物件就是此角色的例項。在java中由具體的類來實現。
       工廠方法模式使用繼承自抽象工廠角色的多個子類來代替簡單工廠模式中的“上帝類”。正如上面所說，這樣便分擔了物件承受的壓力；而且這樣使得結構變得靈活起來——當有新的產品（即暴發戶的汽車）產生時，只要按照抽象產品角色、抽象工廠角色提供的合同來生成，那麼就可以被客戶使用，而不必去修改任何已有的程式碼。可以看出工廠角色的結構也是符合開閉原則的！

       我們還是老規矩，使用一個完整的例子來看看工廠模式各個角色之間是如何來協調的。話說暴發戶生意越做越大，自己的愛車也越來越多。這可苦了那位司機師傅了，什麼車它都要記得，維護，都要經過他來使用！於是暴發戶同情他說：看你跟我這麼多年的份上，以後你不用這麼辛苦了，我給你分配幾個人手，你只管管好他們就行了！於是，工廠方法模式的管理出現了。程式碼如下：

程式碼：

//抽象產品角色，具體產品角色與簡單工廠模式類似，只是變得複雜了些，這裡

略。
//抽象工廠角色
package factory.factorymethod;

public class Magnate_mf {
 public static void main(String[] args){
  Driver driver = new BenzDriver();
  Car car = driver.driverCar();
  car.drive();
 }
}
//抽象產品角色
interface Car{
 public void drive();
}
//抽象工廠角色
interface Driver{
 public Car driverCar();
}
//產品例項角色
class Benz implements Car{

 public void drive() {
  System.out.println("今天開賓士車");
 }

}
class Bmw implements Car{

 public void drive() {
  System.out.println("今天開寶馬車");
 }

}
class Audi implements Car{

 public void drive() {
  System.out.println("今天開奧迪車");
 }

}

/**
 *
 *
 * 這樣一來，將會出現很多工廠，這並不是我們所希望看到的
 * 因此可以根據需要將簡單工程模式與之結合
 *
 *
 */

//工廠例項角色
class BenzDriver implements Driver{
 public Car driverCar() {
  return new Benz();
 }

}
class BmwDriver implements Driver{
 public Car driverCar() {
  return new Bmw();
 }

}
class AudiDriver implements Driver{
 public Car driverCar() {
  return new Audi();
 }

      可以看出工廠方法的加入，使得物件的數量成倍增長。當產品種類非常多時，會出現大量的與之對應的工廠物件，這不是我們所希望的。因為如果不能避免這種情況，可以考慮使用簡單工廠模式與工廠方法模式相結合的方式來減少工廠類：即對於產品樹上類似的種類（一般是樹的葉子中互為兄弟的）使用簡單工廠模式來實現。

五、小結

      讓我們來看看簡單工廠模式、工廠方法模式給我們的啟迪：
如果不使用工廠模式來實現我們的例子，也許程式碼會減少很多--只需要實現已有的車，不使用多型。但是在可維護性上，可擴充套件性上是非常差的（你可以想象一下，新增一輛車後要牽動的類）。因此為了提高擴充套件性和維護性，多寫些程式碼是值得的。

      簡單工廠模式與工廠方法模式真正的避免了程式碼的改動了？沒有。在簡單工廠模式中，新產品的加入要修改工廠角色中的判斷語句；而在工廠方法模式中，要麼將判斷邏輯留在抽象工廠角色中，要麼在客戶程式中將具體工廠角色寫死（就象上面的例子一樣）。而且產品物件建立條件的改變必然會引起工廠角色的修改。
       面對這種情況，Java的反射機制與配置檔案的巧妙結合突破了限制——這在Spring中完美的體現了出來。
六、抽象工廠模式

        先來認識下什麼是產品族： 位於不同產品等級結構中，功能相關聯的產品組成的家族。還是讓我們用一個例子來形象地說明一下吧。回到抽象工廠模式的話題上。可以說，抽象工廠模式和工廠方法模式的區別就在於需要建立物件的複雜程度上。而且抽象工廠模式是三個裡面最為抽象、最具一般性的。抽象工廠模式的用意為：給客戶端提供一個介面，可以建立多個產品族中的產品物件而且使用抽象工廠模式還要滿足一下條件：
     1)系統中有多個產品族，而系統一次只可能消費其中一族產品。
     2)同屬於同一個產品族的產品以其使用。
來看看抽象工廠模式的各個角色（和工廠方法的如出一轍）：
     1)抽象工廠角色： 這是工廠方法模式的核心，它與應用程式無關。是具體工廠角色必須實現的介面或者必須繼承的父類。在java中它由抽象類或者介面來實現。

     2)具體工廠角色：它含有和具體業務邏輯有關的程式碼。由應用程式呼叫以建立對應的具體產品的物件。在java中它由具體的類來實現。

     3)抽象產品角色：它是具體產品繼承的父類或者是實現的介面。在java中一般有抽象類或者介面來實現。

     4)具體產品角色：具體工廠角色所建立的物件就是此角色的例項。在java中由具體的類來實現。
      看過了前兩個模式，對這個模式各個角色之間的協調情況應該心裡有個數了，我就不舉具體的例子了。只是一定要注意滿足使用抽象工廠模式的條件哦。
//
工廠方法模式：
一個抽象產品類，可以派生出多個具體產品類。
一個抽象工廠類，可以派生出多個具體工廠類。
每個具體工廠類只能建立一個具體產品類的例項。

抽象工廠模式：
多個抽象產品類，每個抽象產品類可以派生出多個具體產品類。
一個抽象工廠類，可以派生出多個具體工廠類。
每個具體工廠類可以建立多個具體產品類的例項。