在軟件開發(fā)中，對象創(chuàng)建是一個基礎且頻繁的操作。當對象的創(chuàng)建邏輯變得復雜、需要根據條件動態(tài)創(chuàng)建，或者我們希望將創(chuàng)建過程與使用過程解耦時，直接使用 new 關鍵字可能會帶來代碼的僵化、難以維護和擴展。此時，工廠模式（Factory Pattern）作為一種經典的設計模式，便閃耀登場，為我們提供了一種優(yōu)雅的解決方案。

一、工廠模式的核心思想

工廠模式屬于創(chuàng)建型設計模式。其核心思想是：定義一個用于創(chuàng)建對象的接口（或抽象類），但將具體創(chuàng)建哪個類實例的決定推遲到子類（或具體工廠）中。這樣，客戶端代碼就不再需要直接關心具體對象的實例化細節(jié)，只需與工廠接口和抽象產品交互，從而實現了創(chuàng)建邏輯與使用邏輯的解耦。

簡單來說，就是將 new 這個動作封裝起來，由一個專門的“工廠”來負責生產“產品”。

二、工廠模式的三種形態(tài)

工廠模式主要分為三種形態(tài)：簡單工廠模式、工廠方法模式和抽象工廠模式。它們層層遞進，應對不同復雜度的場景。

1. 簡單工廠模式（Simple Factory）

簡單工廠模式并不屬于GoF的23種設計模式，但它是理解工廠模式的基礎。它通過一個單獨的工廠類，根據傳入的參數，動態(tài)決定創(chuàng)建哪一種產品類的實例。

• 結構：一個具體工廠類，一個抽象產品接口/父類，多個具體產品類。
• 優(yōu)點：客戶端無需知道具體產品類名，只需知道對應參數。
• 缺點：工廠類職責過重，一旦需要添加新產品，就必須修改工廠類的邏輯（通常是增加 if-else 或 switch 分支），這違反了“開閉原則”。
• 適用場景：工廠類負責創(chuàng)建的對象較少，且客戶端不關心創(chuàng)建細節(jié)。

示例：一個圖形繪制程序，根據傳入的“圓形”、“矩形”等字符串，創(chuàng)建對應的 Circle 或 Rectangle 對象。

2. 工廠方法模式（Factory Method）

這是工廠模式的標準形態(tài)。它定義了一個創(chuàng)建對象的抽象方法，由子類決定實例化的具體類。工廠方法模式將對象的實例化推遲到子類。

• 結構：一個抽象工廠類（聲明工廠方法）、多個具體工廠類（實現工廠方法）、一個抽象產品類、多個具體產品類。通常一個具體工廠只生產一種具體產品。
• 優(yōu)點：完全符合“開閉原則”。當需要增加新產品時，只需新增對應的具體工廠和具體產品類，無需修改現有工廠和客戶端代碼。
• 缺點：每增加一個產品，就需要增加一個具體工廠類，會導致類的數量成對增加，增加系統復雜度。
• 適用場景：客戶端不知道它所需要的對象的類，但希望由子類來指定創(chuàng)建的對象。

示例：日志記錄器框架。定義 Logger 抽象產品和 LoggerFactory 抽象工廠?？梢杂?FileLoggerFactory 生產 FileLogger，DatabaseLoggerFactory 生產 DatabaseLogger?？蛻舳送ㄟ^ LoggerFactory 接口獲取日志器，不關心具體的實現。

3. 抽象工廠模式（Abstract Factory）

抽象工廠模式提供了一個創(chuàng)建一系列相關或相互依賴對象的接口，而無需指定它們具體的類。它處理的是“產品族”的創(chuàng)建。

• 結構：一個抽象工廠類（聲明一系列創(chuàng)建產品的方法）、多個具體工廠類（實現創(chuàng)建同一產品族中不同產品的方法）、多個抽象產品類、多個具體產品類（屬于同一產品族）。
• 優(yōu)點：保證客戶端始終使用同一個產品族中的對象。易于交換產品系列（只需更換具體工廠）。
• 缺點：難以支持新種類的產品。如果需要在產品族中增加一個新產品（比如在GUI套件中增加一個新的控件），就需要修改抽象工廠及其所有子類，這違反了“開閉原則”。
• 適用場景：系統需要創(chuàng)建一系列相關的產品對象，且不希望這些產品與具體的創(chuàng)建過程緊密耦合。

示例：跨平臺GUI工具包。有 Button 和 Checkbox 兩個抽象產品。WinFactory 能創(chuàng)建 WinButton 和 WinCheckbox，MacFactory 能創(chuàng)建 MacButton 和 MacCheckbox。應用程序只需綁定一個具體工廠（如 MacFactory），就能獲得風格一致的一整套UI組件。

三、工廠模式的優(yōu)勢

1. 解耦：將對象的創(chuàng)建與使用分離，客戶端代碼只依賴于抽象接口，降低了系統的耦合度。
2. 封裝變化：創(chuàng)建對象的復雜邏輯被封裝在工廠內部，當創(chuàng)建邏輯發(fā)生變化時，不會影響到客戶端。
3. 提高可讀性與可維護性：客戶端代碼更加清晰，職責單一。
4. 便于擴展（尤其是工廠方法模式）：符合開閉原則，新增產品類型時擴展方便。
5. 隱藏具體類：客戶端可能根本不知道具體創(chuàng)建的是哪個類的實例。

四、實踐中的選擇

在實踐中，選擇哪種工廠模式取決于業(yè)務的復雜度：

• 如果產品類型固定且較少，創(chuàng)建邏輯簡單，可以考慮簡單工廠。
• 如果預計產品類型會頻繁擴展，且希望遵循開閉原則，工廠方法是首選。
• 如果系統需要生產一系列相關聯、配套使用的產品對象，抽象工廠模式則能大顯身手。

###

工廠模式不僅僅是“不要用 new”的教條，其背后蘊含的是依賴倒置和面向接口編程的深刻思想。它通過將具體類的實例化延遲，賦予了程序更大的靈活性和可擴展性，是構建高內聚、低耦合軟件系統的利器。理解并善用工廠模式，是邁向高級軟件工程師的重要一步。