設計模式-(3)簡單工廠模式(Simple Factory Pattern)
一、引言
在面向物件程式設計中, 最通常的方法是一個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)看為工廠方法模式的一種特例,兩者歸為一類。
工廠方法模式:
一個抽象產品類,可以派生出多個具體產品類。
一個抽象工廠類,可以派生出多個具體工廠類。
每個具體工廠類只能建立一個具體產品類的例項。
抽象工廠模式:
多個抽象產品類,每個抽象產品類可以派生出多個具體產品類。
一個抽象工廠類,可以派生出多個具體工廠類。
每個具體工廠類可以建立多個具體產品類的例項。
區別:
工廠方法模式只有一個抽象產品類,而抽象工廠模式有多個。
工廠方法模式的具體工廠類只能建立一個具體產品類的例項,而抽象工廠模式可以建立多個。
四、簡單工廠模式
說到簡單工廠,自然的第一個疑問當然就是什麼是簡單工廠模式了? 在現實生活中工廠是負責生產產品的,同樣在設計模式中,簡單工廠模式我們也可以理解為負責生產物件的一個類
建立一個工廠(一個函式或一個類方法)來製造新的物件。
分佈說明引子:從無到有。客戶自己建立寶馬車,然後拿來用。
public class BMW320
{
public BMW320()
{
Console.WriteLine("製造-->BMW320");
}
}
public class BMW523
{
public BMW523()
{
Console.WriteLine("製造-->BMW523");
}
}
public class Customer {
public static void main(String[] args)
{
BMW320 bmw320 = new BMW320();
BMW523 bmw523 = new BMW523();
}
}
客戶需要知道怎麼去建立一款車,客戶和車就緊密耦合在一起了.為了降低耦合,就出現了工廠類,把建立寶馬的操作細節都放到了工廠裡面去,客戶直接使用工廠的建立工廠方法,傳入想要的寶馬車型號就行了,而不必去知道建立的細節.這就是工業革命了:簡單工廠模式
即我們建立一個工廠類方法來製造新的物件。
public class Factory
{
public BMW CreateBMW(int type)
{
switch (type)
{
case 320:
return new BMW320();
case 523:
return new BMW523();
default:
break;
}
return null;
}
}
public class Customer
{
public static void main(String[] args)
{
Factory factory = new Factory();
BMW bmw320 = factory.CreateBMW(320);
BMW bmw523 = factory.CreateBMW(523);
}
}
三、總結
看完簡單工廠模式的實現之後,你和你的小夥伴們肯定會有這樣的疑惑(因為我學習的時候也有)——這樣我們只是把變化移到了工廠類中罷了,好像沒有變化的問題,因為如果新增其他車系時,此時我們還是需要修改工廠類中的方法(也就是多加case語句,沒應用簡單工廠模式之前,修改的是客戶類)。我首先要說:你和你的小夥伴很對,這個就是簡單工廠模式的缺點所在(這個缺點後面介紹的工廠方法可以很好地解決),然而,簡單工廠模式與之前的實現也有它的優點:
1)解決了客戶端直接依賴於具體物件的問題,客戶端可以消除直接建立物件的責任,而僅僅是消費產品。
2)實現了對責任的分割。
3)起到了程式碼複用的作用,因為在沒有工廠類時,所有的客戶呼叫都有直接new,然而有了簡單工廠之後,此時簡單工廠的造車方法就讓所有客戶共用了。(同時這點也是簡單工廠方法的缺點——因為工廠類集中了所有產品建立邏輯,一旦不能正常工作,整個系統都會受到影響,也沒什麼不好理解的,就如事物都有兩面性一樣道理)
雖然上面已經介紹了簡單工廠模式的缺點,下面還是總結下簡單工廠模式的缺點:
1)工廠類集中了所有產品建立邏輯,一旦不能正常工作,整個系統都會受到影響(通俗地意思就是:一旦工廠類罷工了,使用這個工廠的客戶就沒有車可以使用了)
2)系統擴充套件困難,一旦新增新產品就不得不修改工廠邏輯,這樣就會造成工廠邏輯過於複雜。
瞭解了簡單工廠模式之後的優缺點之後,我們之後就可以知道簡單工廠的應用場景了:
1)當工廠類負責建立的物件比較少時可以考慮使用簡單工廠模式
2)客戶如果只知道傳入工廠類的引數,對於如何建立物件的邏輯不關心時可以考慮使用簡單工廠模式
簡單工廠模式又稱靜態工廠方法模式。從命名上就可以看出這個模式一定很簡單。
它存在的目的很簡單:定義一個用於建立物件的介面。
先來看看它的組成:
1) 工廠類角色:這是本模式的核心,含有一定的商業邏輯和判斷邏輯,用來建立產品
2) 抽象產品角色:它一般是具體產品繼承的父類或者實現的介面。
3) 具體產品角色:工廠類所建立的物件就是此角色的例項。
下面我們從開閉原則(對擴充套件開放;對修改封閉)上來分析下簡單工廠模式。當客戶不再滿足現有的車型號的時候,想要一種速度快的新型車,只要這種車符合抽象產品制定的合同,那麼只要通知工廠類知道就可以被客戶使用了。所以對產品部分來說,它是符合開閉原則的;但是工廠部分好像不太理想,因為每增加一種新型車,都要在工廠類中增加相應的建立業務邏輯(createBMW(int type)方法需要新增case),這顯然是違背開閉原則的。可想而知對於新產品的加入,工廠類是很被動的。對於這樣的工廠類,我們稱它為全能類或者上帝類。
我們舉的例子是最簡單的情況,而在實際應用中,很可能產品是一個多層次的樹狀結構。由於簡單工廠模式中只有一個工廠類來對應這些產品,所以這可能會把我們的上帝累壞了,也累壞了我們這些程式設計師。
於是工廠方法模式作為救世主出現了。 工廠類定義成了介面,而每新增的車種型別,就增加該車種型別對應工廠類的實現,這樣工廠的設計就可以擴充套件了,而不必去修改原來的程式碼。