C 設計模式之工廠方法模式

別名：虛擬構造器、factory method

用於建立物件的介面，讓子類決定建立哪乙個類。工廠方法模式使乙個類的例項化延遲到子類。

在軟體系統中，經常面臨著"某個物件『』的建立工作；由於需求的變化，這個物件的具體實現經常面臨著劇烈的變化，但是它卻擁有這比較穩定的介面。

問題來了：

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

舉例理解：

絕地求生中有很多車（轎車，吉普車，蹦蹦等），我現在需要乙個測試車工具類，測試這些車的功能（啟動，轉向，停止等）。而這個車測試類需要可以測試所有滿足車的抽象類的車的具體類（即便後面在增加幾種型別，這個測試類也不需要改變）。

解決方案：

建立乙個車型別的介面和車型別的工廠介面。然後每種具體的車(轎車，吉普…)都去實現車型別的介面，然後在建立乙個自己的工廠並實現型別的工廠介面。

這樣不管後面需要增加什麼樣的車，只有他滿足車的介面都可以按照這這種方式實現。

歸納總結：

工廠方法模式通過物件導向的手法，將所要建立的具體物件工作延遲到子類，從而實現一種擴充套件（而非更改）的策略，較好地解決了這種緊耦合的關係。

產品（product）將會對介面進行宣告。對於所有由建立者及其子類構建的物件，這些介面都是通用的。

具體產品（concrete products）是產品介面的不同實現。

建立者（creator）類宣告返回產品物件的工廠方法。該方法的返回物件型別必須與產品介面相匹配。

你可以將工廠方法宣告為抽象方法，強制要求每個子類以不同方式實現該方法。或者，你也可以在基礎工廠方法中返回預設產品型別。

ps：雖然它的名字是建立者，但他最主要的職責並不是建立產品。一般來說，建立者類包含一些與產品相關的核心業務邏輯。工廠方法將這些邏輯處理從具體產品類中分離出來。比如，你們公司有乙個給程式設計師培訓的部門。但是，公司的主要工作還是編寫**，而非培訓程式設計師。

具體建立者（concrete creators）將會重寫基礎工廠方法，使其返回不同型別的產品。

ps: 並不一定每次呼叫工廠方法都會建立新的例項。工廠方法也可以返回快取、物件池或其他**的已有物件。

優點：

缺點：

適用性：

對照：

工廠方法模式主要用於隔離類物件的使用者和具體型別之間的耦合關係。面對乙個經常變化的具體型別，緊耦合關係會導致程式的脆弱。

實現方式：

讓所有產品都遵循同一介面。該介面必須宣告對所有產品都有意義的方法。（所有子類都能用上）

在建立類中新增乙個空的工廠方法。該方法的返回型別必須遵循通用的產品介面。(上面宣告的那個介面)

在建立類**中找到對於建構函式的所有引用。將它們依次替換為對於工廠方法的呼叫，同時將建立方法(new)的**移入工廠方法。

為工廠方法中的每種產品編寫乙個工廠子類，然後在子類中重寫工廠方法，並將基本方法中的相關建立**移動到工廠方法中。

如果應用中的產品型別太多，那麼為每個產品建立子類工作量就很大，這時你也可以在子類中在找出幾個類的共同點建立乙個基類。

示例**：

還是以上面說的那個測試車為例：首先有個抽象車類(此類包含的所有宣告必頂對所有子類都有意義【比如：宣告了乙個測試耗油量的方法，若此時你需要測試的車中有電動車，那麼這個方法就不應該宣告在抽象類(介面)中】)

/// 
/// 車的抽象(介面)
/// 
public
abstract
class
car

建立乙個工廠方法介面

/// /// 車工廠 /// public abstract class ca***ctory

3.建立具體車類 – 實現1建立介面

/// 
/// 吉普車
/// 
class
jipucar
:car
public
override
void
stop()
public
override
void
turn()
}

4.建立具體車類（對應3）的工廠類 – 實現2建立介面

/// /// 吉普車工廠 /// public class jipuca***ctory :ca***ctory

}

放到測試框架中進行測試：

/// /// 車測試框架 -- 所有車都可以被測試 /// class cartestframework

}

6.啟動測試框架，檢視測試結果

按照此邏輯，當再有其他車需要進行測試時，只需要按照3,4步驟中實現對應的具體車類和對應的工廠類即可，進行測試。這樣就保證了有需求增加時只需要我們拓展（新建類）而不需要修改現有的**。

C 設計模式 之 工廠方法模式

工廠方法模式 C 設計模式之1 工廠方法模式

C 設計模式之工廠方法模式

C 設計模式之工廠方法模式

相關推薦

C 設計模式之工廠方法模式