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

>>> 技術話題—商業文明的嶄新時代 >>>

簡體傳統

2005.12.19 李建忠

從耦合關系談起

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

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

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

抽象部分變化慢，細節（具體）部分變化快；高層部分變化慢，底層部分變化快。

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

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

動機（Motivation）

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

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

意圖（Intent）

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

——《設計模式》GoF

結構（Structure）

例說Factory Method應用

汽車

汽車測試

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

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

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

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

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

Car的具體實現

Car工廠

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

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