C#面向對象設計模式縱橫談 第5講:Factory Method 工廠方法模式

>>>  技術話題—商業文明的嶄新時代  >>> 簡體     傳統

2005.12.19 李建忠

從耦合關系談起

耦合關系直接決定著軟件面對變化時的行為

-模塊與模塊之間的緊耦合使得軟件面對變化時,相關模塊都要隨之更改

image

-模塊與模塊之間的松耦合使得軟件面對變化時,一些模塊更容易被替換或者更改,但其他模塊保持不變

image

 

抽象部分變化慢,細節(具體)部分變化快;高層部分變化慢,底層部分變化快。

當我們對于系統的認識無法梳理出上面的圖時,最好不要一開始就用設計模式,設計模式其實是一個演繹的過程。當我們對軟件認識不斷深化時,慢慢就會知道哪些是主要的,哪些是次要的,就能梳理出一個抽象和具體的層次,再考慮用哪種設計模式。

第二幅圖滿足了依賴倒置原則,中間的主線是變化慢的部分,分支都是用接口相連。這樣的松耦合使得模塊與模塊之間的連接用接口連接,接口是相對穩定的部分,接口的實現是相對變化的部分。例如:去幫我買一條毛巾,只告訴了是毛巾這樣事物,而毛巾的具體品種、顏色并沒有具體的需求。大自然創造的世界,遍地都是松耦合、高內聚。例如屋子里的凳子和桌子、床單和被子等,當我們需要換床單時,是不需要換床的。床和床單之間有一個接口,床是主線,床需要床單的接口,只要具體的床單滿足這個尺寸接口,就可以接上。主邏輯的變化成本比輔邏輯的變化成本高,所以盡量讓輔邏輯的變化較少的影響主邏輯。因此我們設計軟件的原則是,先穩定下接口,再考慮具體實現。

 

動機(Motivation)

在軟件系統張中,經常面臨著“某個對象”的創建工作:由于需求的變化,這個對象(的具體實現)經常面臨著劇烈的變化,但是它卻擁有比較穩定的接口

如何應對這種變化?如何提供一種“封裝機制”來隔離出“這個易變對象”的變化,從而保持系統中“其他依賴對象的對象”不隨著需求改變而改變

 

意圖(Intent)

定義一個用于創建對象的接口,讓子類決定實例化哪一個類。Factory Method使得一個類的實例化延遲到子類。

——《設計模式》GoF

 

結構(Structure)

image

 

例說Factory Method應用

汽車

image

汽車測試

image

但是這種測試只能測試一種Car,如果要測試其他類型的Car,需要修改代碼并重新編譯。

為了應對這種改變,我們需要把Car先變成抽象類。

image

然后我們在客戶程序使用的時候,把所有的Car都換成抽象的AbstractCar,這樣客戶程序就不需要了解具體測試的是哪個Car了。客戶程序如下

image

但這種代碼明顯是錯誤的,抽象類不能直接實例化,因此我們比較好的方法是把抽象的Car傳遞進來

image

如果現在我們需要Car的多個實例,那么參數只接收一個抽象的Car就顯得不那么適用了。我們可能想到的方法是把傳進來的Car做一個淺拷貝Memberwise,但是淺拷貝是一個protected方法,并且不能拷貝引用,但是這也是有辦法解決的,這種克隆的做法可以,但是現在我們研究另一種做法。我們希望能有一個創建Car的工廠,這樣我們在客戶程序就不需要關心Car的實例,只管用這個工廠去創建具體的Car。

image

Car的具體實現

image

 

Car工廠

image

 

 

 

 

(糾正:CarFactory類中的CreateCar方法應該返回抽象的AbstractCar類型,CarFactory的類和具體HongqiCarFactory的類在實際中應該放在兩個不同的文件夾中)

因為客戶程序需要用到CarFactory,所以CarFactory中不應該涉及到Car的具體實現,CarFactory應該是一個抽象的工廠類,因此HongqiCar的工廠需要一個繼承自抽象CarFactory的具體工廠。在應用程序調用的時候,傳入客戶程序的工廠應該是具體的HongqiCarFactory工廠。

image

當想換具體Car的時候,只需要創建一個新的Car繼承自AbstractCar,并新建一個具體CarFactory工廠繼承自抽象CarFactory。然后在具體的應用中把具體的Car工廠參數修改即可。當然,完全可以讓具體應用的代碼也不用修改,把變化轉嫁到配置文件中去。

 

Factory Method模式的幾個要點

Factory Method模式主要用于隔離類對象的使用者和具體類型之間的耦合關系。面對一個經常變化的具體類型,緊耦合關系會導致軟件的脆弱。

Factory Method模式通過面向對象的手法,將所要創建的具體對象工作延遲到子類,從而實現一種擴展(而非更改)的策略,較好地解決了這種緊耦合關系。

Factory Method模式解決“單個對象”的需求變化;

AbstractFactory模式解決“系列對象”的需求變化;

Builder模式解決“對象部分”的需求變化;

 

.NET框架中的Factory Method應用

SOAP、ASP.Net HttpHandler等

2010.9.26


MSDN 網絡廣播 李建忠 2013-08-22 08:43:35

[新一篇] C#面向對象設計模式縱橫談 第4講:Builder 生成器模式

[舊一篇] C#面向對象設計模式縱橫談 第6講:Prototype 原型模式
回頂部
寫評論


評論集


暫無評論。

稱謂:

内容:

驗證:


返回列表