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


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

 

模式的問題:你如何能輕松方便地構造對象實例,而不必關心構造對象實例的細節和復雜過程呢?

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

實現:

一、引言
    1)還沒有工廠時代:假如還沒有工業革命,如果一個客戶要一款寶馬車,一般的做法是客戶去創建一款寶馬車,然后拿來用。
    2)簡單工廠模式:后來出現工業革命。用戶不用去創建寶馬車。因為客戶有一個工廠來幫他創建寶馬.想要什么車,這個工廠就可以建。比如想要320i系列車。工廠就創建這個系列的車。即工廠可以創建產品。
    3)工廠方法模式時代:為了滿足客戶,寶馬車系列越來越多,如320i,523i,30li等系列一個工廠無法創建所有的寶馬系列。於是由單獨分出來多個具體的工廠。每個具體工廠創建一種系列。即具體工廠類只能創建一個具體產品。但是寶馬工廠還是個抽象。你需要指定某個具體的工廠才能生產車出來。

   4)抽象工廠模式時代:隨着客戶的要求越來越高,寶馬車必須配置空調。於是這個工廠開始生產寶馬車和需要的空調。

   最終是客戶只要對寶馬的銷售員說:我要523i空調車,銷售員就直接給他523i空調車了。而不用自己去創建523i空調車寶馬車.

   這就是工廠模式。

二、分類 
        工廠模式主要是為創建對象提供過渡接口,以便將創建對象的具體過程屏蔽隔離起來,達到提高靈活性的目的。 
工廠模式可以分為三類: 

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

 這三種模式從上到下逐步抽象,並且更具一般性。 
        GOF在《設計模式》一書中將工廠模式分為兩類:工廠方法模式(Factory Method)與抽象工廠模式(Abstract Factory)。

        將簡單工廠模式(Simple Factory)看為工廠方法模式的一種特例,兩者歸為一類。 

三、區別 
工廠方法模式:
一個抽象產品類,可以派生出多個具體產品類。   
一個抽象工廠類,可以派生出多個具體工廠類。   
每個具體工廠類只能創建一個具體產品類的實例。
抽象工廠模式:
多個抽象產品類,每個抽象產品類可以派生出多個具體產品類。   
一個抽象工廠類,可以派生出多個具體工廠類。   
每個具體工廠類可以創建多個具體產品類的實例。   
區別:
工廠方法模式只有一個抽象產品類,而抽象工廠模式有多個。   
工廠方法模式的具體工廠類只能創建一個具體產品類的實例,而抽象工廠模式可以創建多個。
兩者皆可。 

 四、簡單工廠模式 
建立一個工廠(一個函數或一個類方法)來制造新的對象。
分布說明引子:從無到有。客戶自己創建寶馬車,然后拿來用。

 

 

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),這顯然是違背開閉原則的。可想而知對於新產品的加入,工廠類是很被動的。對於這樣的工廠類,我們稱它為全能類或者上帝類。 
        我們舉的例子是最簡單的情況,而在實際應用中,很可能產品是一個多層次的樹狀結構。由於簡單工廠模式中只有一個工廠類來對應這些產品,所以這可能會把我們的上帝累壞了,也累壞了我們這些程序員。
        於是工廠方法模式作為救世主出現了。 工廠類定義成了接口,而每新增的車種類型,就增加該車種類型對應工廠類的實現,這樣工廠的設計就可以擴展了,而不必去修改原來的代碼。
五、工廠方法模式 
        工廠方法模式去掉了簡單工廠模式中工廠方法的靜態屬性,使得它可以被子類繼承。這樣在簡單工廠模式里集中在工廠方法上的壓力可以由工廠方法模式里不同的工廠子類來分擔。 
工廠方法模式組成: 
       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(轉載請說明出處)


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM