JAVA設計模式之工廠模式(簡單工廠模式+工廠方法模式)

在面向對象編程中, 最一般的方法是一個new操做符產生一個對象實例,new操做符就是用來構造對象實例的。可是在一些狀況下, new操做符直接生成對象會帶來一些問題。舉例來講, 許多類型對象的創造須要一系列的步驟: 你可能須要計算或取得對象的初始設置; 選擇生成哪一個子對象實例; 或在生成你須要的對象以前必須先生成一些輔助功能的對象。 在這些狀況,新對象的創建就是一個 「過程」，不只是一個操做，像一部大機器中的一個齒輪傳動。

 

模式的問題：你如何能輕鬆方便地構造對象實例，而沒必要關心構造對象實例的細節和複雜過程呢？

解決方案：創建一個工廠來建立對象

實現：

1、引言
    1）尚未工廠時代：假如尚未工業革命，若是一個客戶要一款寶馬車,通常的作法是客戶去建立一款寶馬車，而後拿來用。
    2）簡單工廠模式：後來出現工業革命。用戶不用去建立寶馬車。由於客戶有一個工廠來幫他建立寶馬.想要什麼車，這個工廠就能夠建。好比想要320i系列車。工廠就建立這個系列的車。即工廠能夠建立產品。
    3）工廠方法模式時代：爲了知足客戶，寶馬車系列愈來愈多，如320i，523i,30li等系列一個工廠沒法建立全部的寶馬系列。因而由單獨分出來多個具體的工廠。每一個具體工廠建立一種系列。即具體工廠類只能建立一個具體產品。可是寶馬工廠仍是個抽象。你須要指定某個具體的工廠才能生產車出來。

   4）抽象工廠模式時代：隨着客戶的要求愈來愈高，寶馬車必須配置空調。因而這個工廠開始生產寶馬車和須要的空調。

   最終是客戶只要對寶馬的銷售員說：我要523i空調車，銷售員就直接給他523i空調車了。而不用本身去建立523i空調車寶馬車.

   這就是工廠模式。

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

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

 這三種模式從上到下逐步抽象，而且更具通常性。 
        GOF在《設計模式》一書中將工廠模式分爲兩類：工廠方法模式（Factory Method）與抽象工廠模式（Abstract Factory）。

        將簡單工廠模式（Simple Factory）看爲工廠方法模式的一種特例，二者歸爲一類。 

3、區別 
工廠方法模式：
一個抽象產品類，能夠派生出多個具體產品類。   
一個抽象工廠類，能夠派生出多個具體工廠類。   
每一個具體工廠類只能建立一個具體產品類的實例。
抽象工廠模式：
多個抽象產品類，每一個抽象產品類能夠派生出多個具體產品類。   
一個抽象工廠類，能夠派生出多個具體工廠類。   
每一個具體工廠類能夠建立多個具體產品類的實例。   
區別：
工廠方法模式只有一個抽象產品類，而抽象工廠模式有多個。   
工廠方法模式的具體工廠類只能建立一個具體產品類的實例，而抽象工廠模式能夠建立多個。
二者皆可。 

 4、簡單工廠模式 
創建一個工廠（一個函數或一個類方法）來製造新的對象。
分佈說明引子：從無到有。客戶本身建立寶馬車，而後拿來用。

 

 

copy ?

 

public BMW320 {  

•      BMW320(){  
•         System.out.println( }  
•   
•   BMW523 {  
•      BMW523(){  
•         System.out.println( }  
•   
•   Customer {  
•        main(String[] args) {  
•         BMW320 bmw320 =  BMW320();  
•         BMW523 bmw523 =  BMW523();  
•     }  
• }  

客戶須要知道怎麼去建立一款車,客戶和車就緊密耦合在一塊兒了.爲了下降耦合,就出現了工廠類,把建立寶馬的操做細節都放到了工廠裏面去,客戶直接使用工廠的建立工廠方法,傳入想要的寶馬車型號就好了,而沒必要去知道建立的細節.這就是工業革命了：簡單工廠模式

即咱們創建一個工廠類方法來製造新的對象。如圖：

產品類：

copy ?

 

abstract BMW {  

•      BMW(){  
•           
•     }  
• }  
•   
•   BMW320  BMW {  
•      BMW320() {  
•         System.out.println( }  
•   BMW523  BMW{  
•      BMW523(){  
•         System.out.println(    }  
• }  

工廠類：

copy ?

 

public Factory {  

•      BMW createBMW( type) {  
•          (type) {  
•           
•          :  
•               BMW320();  
•   
•          :  
•               BMW523();  
•   
•         :  
•             ;  
•         }  
•          ;  
•     }  
• }  

客戶類：

copy ?

 

public Customer {  

•        main(String[] args) {  
•         Factory factory =  Factory();  
•         BMW bmw320 = factory.createBMW();  
•         BMW bmw523 = factory.createBMW();  
•     }  
• }  

   簡單工廠模式又稱靜態工廠方法模式。重命名上就能夠看出這個模式必定很簡單。它存在的目的很簡單：定義一個用於建立對象的接口。 
      先來看看它的組成： 
         1) 工廠類角色：這是本模式的核心，含有必定的商業邏輯和判斷邏輯，用來建立產品
         2) 抽象產品角色：它通常是具體產品繼承的父類或者實現的接口。         
         3) 具體產品角色：工廠類所建立的對象就是此角色的實例。在Java中由一個具體類實現。 
        
        下面咱們從開閉原則（對擴展開放；對修改封閉）上來分析下簡單工廠模式。當客戶再也不知足現有的車型號的時候，想要一種速度快的新型車，只要這種車符合抽象產品制定的合同，那麼只要通知工廠類知道就能夠被客戶使用了。因此對產品部分來講，它是符合開閉原則的；可是工廠部分好像不太理想，由於每增長一種新型車，都要在工廠類中增長相應的建立業務邏輯（createBMW(int type)方法須要新增case），這顯然是違背開閉原則的。可想而知對於新產品的加入，工廠類是很被動的。對於這樣的工廠類，咱們稱它爲全能類或者上帝類。 
        咱們舉的例子是最簡單的狀況，而在實際應用中，極可能產品是一個多層次的樹狀結構。因爲簡單工廠模式中只有一個工廠類來對應這些產品，因此這可能會把咱們的上帝累壞了，也累壞了咱們這些程序員。
        因而工廠方法模式做爲救世主出現了。 工廠類定義成了接口,而每新增的車種類型,就增長該車種類型對應工廠類的實現,這樣工廠的設計就能夠擴展了,而沒必要去修改原來的代碼。
5、工廠方法模式 
        工廠方法模式去掉了簡單工廠模式中工廠方法的靜態屬性，使得它能夠被子類繼承。這樣在簡單工廠模式裏集中在工廠方法上的壓力能夠由工廠方法模式裏不一樣的工廠子類來分擔。 
工廠方法模式組成： 
       1)抽象工廠角色： 這是工廠方法模式的核心，它與應用程序無關。是具體工廠角色必須實現的接口或者必須繼承的父類。在java中它由抽象類或者接口來實現。 
       2)具體工廠角色：它含有和具體業務邏輯有關的代碼。由應用程序調用以建立對應的具體產品的對象。 
       3)抽象產品角色：它是具體產品繼承的父類或者是實現的接口。在java中通常有抽象類或者接口來實現。 
       4)具體產品角色：具體工廠角色所建立的對象就是此角色的實例。在java中由具體的類來實現。 
       工廠方法模式使用繼承自抽象工廠角色的多個子類來代替簡單工廠模式中的「上帝類」。正如上面所說，這樣便分擔了對象承受的壓力；並且這樣使得結構變得靈活 起來——當有新的產品產生時，只要按照抽象產品角色、抽象工廠角色提供的合同來生成，那麼就能夠被客戶使用，而沒必要去修改任何已有 的代碼。能夠看出工廠角色的結構也是符合開閉原則的！ 

代碼以下： 

產品類：

copy ?

 

abstract BMW {  

•      BMW(){  
•           
•     }  
• }  
•   BMW320  BMW {  
•      BMW320() {  
•         System.out.println(    }  
• }  
•   BMW523  BMW{  
•      BMW523(){  
•         System.out.println( }  

建立工廠類：

copy ?

 

interface }  

•   
•   FactoryBMW320  FactoryBMW{  
•   
•       
•      BMW320 createBMW() {  
•   
•           BMW320();  
•     }  
•   
• }  
•   FactoryBMW523  FactoryBMW {  
•       
•      BMW523 createBMW() {  
•   
•           BMW523();  
•     }  
• }  

客戶類：

copy ?

 

public Customer {  

•        main(String[] args) {  
•         FactoryBMW320 factoryBMW320 =  FactoryBMW320();  
•         BMW320 bmw320 = factoryBMW320.createBMW();  
•   
•         FactoryBMW523 factoryBMW523 =  FactoryBMW523();  
•         BMW523 bmw523 = factoryBMW523.createBMW();  
•     }  
• }  

 工廠方法模式彷彿已經很完美的對對象的建立進行了包裝，使得客戶程序中僅僅處理抽象產品角色提供的接口，但使得對象的數量成倍增加。當產品種類很是多時，會出現大量的與之對應的工廠對象，這不是咱們所但願的。

以上就是簡單工廠模式，工廠方法模式，抽象工廠模式在這裏。

 

例子背景：

隨着客戶的要求愈來愈高，寶馬車須要不一樣配置的空調和發動機等配件。因而這個工廠開始生產空調和發動機，用來組裝汽車。這時候工廠有兩個系列的產品:空調和發動機。寶馬320系列配置A型號空調和A型號發動機，寶馬230系列配置B型號空調和B型號發動機。

概念：

   抽象工廠模式是工廠方法模式的升級版本，他用來建立一組相關或者相互依賴的對象。好比寶馬320系列使用空調型號A和發動機型號A，而寶馬230系列使用空調型號B和發動機型號B，那麼使用抽象工廠模式，在爲320系列生產相關配件時，就無需制定配件的型號，它會自動根據車型生產對應的配件型號A。

針對百度百科上對於抽象工廠模式的簡介，結合本例以下：

當每一個抽象產品都有多於一個的具體子類的時候（空調有型號A和B兩種，發動機也有型號A和B兩種），工廠角色怎麼知道實例化哪個子類呢？好比每一個抽象產品角色都有兩個具體產品（產品空調有兩個具體產品空調A和空調B）。抽象工廠模式提供兩個具體工廠角色（寶馬320系列工廠和寶馬230系列工廠），分別對應於這兩個具體產品角色，每個具體工廠角色只負責某一個產品角色的實例化。每個具體工廠類只負責建立抽象產品的某一個具體子類的實例。

抽象工廠模式代碼

 產品類： 

copy ?

 

//發動機以及型號   public Engine {    

•   
• }    
•   EngineA  Engine{    
•      EngineA(){    
•         System.out.println( }    
•   EngineBextends Engine{    
•      EngineB(){    
•         System.out.println(    }    
• }    
•   
•   
•   Aircondition {    
•   
• }    
•   AirconditionA  Aircondition{    
•      AirconditionA(){    
•         System.out.println(    }    
• }    
•   AirconditionB  Aircondition{    
•      AirconditionB(){    
•         System.out.println( }   

建立工廠類：

 

copy ?

 

//建立工廠的接口   public AbstractFactory {    

•       
•      Engine createEngine();  
•       
•      Aircondition createAircondition();   
• }    
•   
•   
•   
•   FactoryBMW320  AbstractFactory{    
•         
•         
•      Engine createEngine() {      
•           EngineA();    
•     }    
•         
•      Aircondition createAircondition() {    
•           AirconditionA();    
•     }    
• }    
•   
•   FactoryBMW523  AbstractFactory {    
•     
•          
•      Engine createEngine() {      
•           EngineB();    
•     }    
•         
•      Aircondition createAircondition() {    
•           AirconditionB();    
•     }    
•   
•   
• }   

 

客戶:

 

copy ?

 

public Customer {    

•        main(String[] args){    
•           
•         FactoryBMW320 factoryBMW320 =  FactoryBMW320();    
•         factoryBMW320.createEngine();  
•         factoryBMW320.createAircondition();  
•             
•           
•         FactoryBMW523 factoryBMW523 =  FactoryBMW523();    
•         factoryBMW320.createEngine();  
•         factoryBMW320.createAircondition();  
•     }    
• }  

關於抽象工廠模式與工廠方法模式的區別，這裏就不說了，感受多看幾遍例子就能理解，還有不少提到的產品族、等級結構等概念，說了反而更難理解。

抽象工廠模式的起源

下面引用一段 抽象工廠模式的起源：

抽象工廠模式的起源或者最先的應用，是用於建立分屬於不一樣操做系統的視窗構建。好比：命令按鍵（Button）與文字框（Text)都是視窗構建，在UNIX操做系統的視窗環境和Windows操做系統的視窗環境中，這兩個構建有不一樣的本地實現，它們的細節有所不一樣。

在每個操做系統中，都有一個視窗構建組成的構建家族。在這裏就是Button和Text組成的產品族。而每個視窗構件都構成本身的等級結構，由一個抽象角色給出抽象的功能描述，而由具體子類給出不一樣操做系統下的具體實現。

能夠發如今上面的產品類圖中，有兩個產品的等級結構，分別是Button等級結構和Text等級結構。同時有兩個產品族，也就是UNIX產品族和Windows產品族。UNIX產品族由UNIX Button和UNIX Text產品構成；而Windows產品族由Windows Button和Windows Text產品構成。

系統對產品對象的建立需求由一個工程的等級結構知足，其中有兩個具體工程角色，即UnixFactory和WindowsFactory。UnixFactory對象負責建立Unix產品族中的產品，而WindowsFactory對象負責建立Windows產品族中的產品。這就是抽象工廠模式的應用，抽象工廠模式的解決方案以下圖：

顯然，一個系統只可以在某一個操做系統的視窗環境下運行，而不能同時在不一樣的操做系統上運行。因此，系統實際上只能消費屬於同一個產品族的產品。

在現代的應用中，抽象工廠模式的使用範圍已經大大擴大了，再也不要求系統只能消費某一個產品族了。

總結：

不管是簡單工廠模式，工廠方法模式，仍是抽象工廠模式，他們都屬於工廠模式，在形式和特色上也是極爲類似的，他們的最終目的都是爲了解耦。在使用時，咱們沒必要去在乎這個模式到底工廠方法模式仍是抽象工廠模式，由於他們之間的演變經常是使人琢磨不透的。常常你會發現，明明使用的工廠方法模式，當新需求來臨，稍加修改，加入了一個新方法後，因爲類中的產品構成了不一樣等級結構中的產品族，它就變成抽象工廠模式了；而對於抽象工廠模式，當減小一個方法使的提供的產品再也不構成產品族以後，它就演變成了工廠方法模式。

       因此，在使用工廠模式時，只須要關心下降耦合度的目的是否達到了

博客：http://blog.csdn.net/jason0539（轉載請說明出處）