在物件導向分析與設計的領域中，物件的建立方式在系統的可維護性與可擴展性上扮演著關鍵角色。當應用邏輯與具體類別實作緊密耦合時，變更會在程式碼庫中產生連鎖反應，增加技術負債並降低敏捷性。工廠模式提供了一種結構化的方法來管理物件建立，使系統在不硬編碼依賴關係的情況下仍能保持彈性。
本指南探討工廠模式的運作機制、其變體，以及如何有效應用以達成解耦且穩健的架構。我們將檢視其理論基礎、實際實作步驟，以及採用此設計策略所涉及的權衡。
🔍 理解問題：緊密耦合
考慮一個情境，其中客戶端類別需要建立特定類型的服務以執行任務。一種簡單直接的實作方式通常如下：
- 客戶端直接呼叫建構函式。
- 客戶端知道確切的類別名稱。
- 更換實作方式需要修改客戶端程式碼。
這種直接的依賴關係會造成僵化的結構。如果需求轉變為使用不同的實作方式，系統中所有引用原始類別的部分都必須更新。這違反了開閉原則，該原則指出軟體實體應對擴展開放，但對修改封閉。
🏭 什麼是工廠模式？
工廠模式是一種創建型設計模式，它在超類別中提供一個建立物件的介面，但允許子類別改變所要建立的物件類型。與直接使用「new」運算子建立物件不同，建立邏輯被委託給工廠方法或工廠物件。new運算子不同，建立邏輯被委託給工廠方法或工廠物件。
主要特徵包括：
- 抽象： 客戶端與介面或抽象類別互動，而非具體實作。
- 封裝： 建立邏輯被隱藏在工廠內部。
- 彈性： 新的產品類型可以新增，而無需變更客戶端程式碼。
🛠️ 工廠模式的變體
雖然核心概念保持一致，但實作方式會根據系統的複雜度而有所不同。在物件導向設計中，有三種主要變體被使用。
1. 簡單工廠（靜態工廠）
這在嚴格意義上並非GoF（四人組）所定義的設計模式，而是一種設計慣用法。單一類別包含一個工廠方法，根據輸入參數回傳不同類別的實例。
- 使用情境： 產品類型數量少且已知的簡單系統。
- 機制： 靜態方法接受類型識別符，並回傳適當的物件。
- 限制： 為新增產品類型，必須修改工廠類別本身，這違反了開閉原則。
2. 工廠方法模式
此模式定義了一個用於建立物件的介面，但讓子類別決定要實例化的類別。建立邏輯被推遲到子類別中。
- 使用案例： 當一個類別無法預期它必須建立的物件類別時。
- 機制： 基底類別定義了一個建立方法。具體的子類別覆寫此方法以傳回特定的產品實例。
- 優點： 在產品建立方面嚴格遵守開閉原則。
3. 抽象工廠模式
此模式提供了一個介面，用於建立相關或依賴的物件家族，而無需指定其具體的子類別。
- 使用案例： 需要與多個產品家族一起工作的系統（例如，不同操作系統的UI按鈕）。
- 機制： 抽象工廠宣告了用於建立家族中每種產品的方法。具體工廠實作了這些方法。
- 優點： 確保相關產品之間的一致性。
📝 實作工作流程
實作工廠模式需要採取系統性的方法，以確保設計保持乾淨且可維護。請依照以下步驟來規劃您的解決方案。
步驟 1：定義產品介面
首先定義一個所有具體產品都必須遵守的合約。此介面定義了客戶端可用的方法，無論底層實作為何。
- 識別所需的共同行為。
- 建立一個抽象類別或介面。
- 確保所有未來的產品實作都延伸此合約。
步驟 2：建立具體產品類別
開發實作產品介面的特定類別。這些類別包含實際的業務邏輯。
- 實作介面中定義的方法。
- 保持它們與工廠邏輯獨立。
- 確保它們不知道是哪個工廠創造了它們。
步驟 3：定義工廠介面
建立一個宣告用於建立產品方法的工廠介面。這作為建立過程的合約。
- 為每種產品類型定義對應的方法。
- 保持工廠僅專注於實例化。
步驟 4：實作具體工廠
建立實作工廠介面的具體工廠類別。在這些類別中，實例化特定的具體產品。
- 將工廠對應到特定的產品族。
- 傳回具體產品的新實例。
- 避免複雜邏輯；專注於物件建構。
步驟 5：與客戶端整合
更新客戶端程式碼，使其依賴工廠介面而非具體類別。客戶端向工廠請求物件。
- 將工廠注入客戶端，或從登錄中取得。
- 透過產品介面使用傳回的物件。
- 從客戶端移除直接實例化的邏輯。
📊 工廠變體比較
選擇合適的變體取決於專案的具體需求。下表概述了差異。
| 功能 | 簡單工廠 | 工廠方法 | 抽象工廠 |
|---|---|---|---|
| 建立邏輯 | 單一類別方法 | 子類別方法 | 族別介面 |
| 可擴展性 | 低（修改工廠） | 高（新增子類別） | 高（新增具體工廠） |
| 複雜度 | 低 | 中等 | 高 |
| 產品系列 | 單一類型專注 | 單一類型專注 | 多個相關類型 |
| 開放/封閉 | 違反 | 遵守 | 遵守 |
✅ 使用工廠模式的好處
採用此模式可為應用程式帶來顯著的結構優勢。
- 解耦：客戶端程式碼與具體類別解耦。當實作變更時，系統的穩定性更高。
- 集中化邏輯： 所有實例化邏輯都集中於一個位置，便於除錯與修改。
- 單一職責： 工廠負責建立，產品類別負責行為。這種關注點分離改善了程式碼組織。
- 組態管理： 工廠可輕鬆與組態檔整合，以在執行階段決定要實例化的產品。
- 安全性： 您可以限制客戶端直接存取建構函式，從而控制物件的建立方式。
⚠️ 缺點與考量
雖然強大，但此模式並非萬能解方。它引入的複雜性必須與其帶來的好處權衡。
- 複雜度增加： 引入工廠會增加間接層級。簡單的應用程式可能變得過度設計。
- 程式碼量增加： 需要更多的類別（介面、具體產品、工廠、具體工廠），增加總程式碼行數。
- 可讀性： 理解物件建立的流程需要追蹤多個類別，對新手開發者而言可能令人困惑。
- 測試負擔： 單元測試可能需要模擬工廠或特定的工廠實作，以隔離行為。
🚀 實施的最佳實踐
為了確保工廠模式帶來價值而非噪音，請遵循以下指南。
- 保持簡單： 從簡單工廠開始。只有當複雜性要求時，才轉向工廠方法或抽象工廠。
- 使用依賴注入： 將工廠注入客戶端，而不是讓客戶端創建工廠實例。這有助於測試和切換實現。
- 命名慣例： 為工廠類使用清晰的名稱（例如，
PaymentFactory）和產品（例如，CreditCardPayment）以保持清晰。 - 避免副作用： 工廠方法應僅創建物件為理想狀態。避免在工廠內部包含繁重的業務邏輯。
- 妥善處理錯誤： 如果工廠無法創建請求的產品，請定義明確的錯誤處理策略，例如拋出特定異常。
🧩 與SOLID原則的整合
工廠模式與多個SOLID原則密切相關，這些原則指導物件導向設計。
依賴反轉原則（DIP）
高階模組不應依賴低階模組。兩者都應依賴抽象。工廠模式透過讓客戶端依賴產品介面和工廠介面，而非具體類別，來強制執行此原則。
開閉原則（OCP）
實體應對擴展開放，但對修改封閉。透過使用工廠方法或抽象工廠，您可以透過新增類別來添加新的產品類型，而無需修改現有的客戶端程式碼。
單一責任原則（SRP）
一個類別應只有一個變更的理由。工廠模式將知道如何建立物件的責任與使用這些物件的責任分離。
⚠️ 應避免的常見陷阱
即使經驗豐富的開發人員也可能錯誤應用此模式。請留意這些常見錯誤。
- 過度設計： 在僅需直接呼叫建構函式即可的簡單應用中使用抽象工廠。這會增加不必要的重複程式碼。
- 隱藏的依賴： 如果工廠實例化具有複雜依賴關係的物件，則這些依賴關係必須在工廠內部正確管理。
- 意大利麵條式邏輯： 如果工廠類別因多個條件而變得過於龐大，就會違反單一職責原則（SRP）。應將邏輯拆分為較小的工廠類別。
- 忽略效能： 在高效率的場景中，工廠呼叫的開銷可能微不足道，但在沒有使用物件池的情況下於工廠內建立昂貴物件，可能會影響記憶體使用。
🔄 使用工廠管理生命週期
工廠模式通常用於管理物件的生命週期，而不僅僅是其建立。工廠可以決定物件應全新建立，還是從快取中取得。
- 單例管理： 工廠可確保資源僅存在一個實例。
- 資源池化： 對於昂貴的資源，工廠可從資源池中返回一個實例，而非建立新的實例。
- 狀態管理： 工廠可根據設定資料，以特定狀態初始化物件。
🧪 測試策略
測試依賴工廠的程式碼，需要特定的方法來確保可靠性。
- 模擬工廠： 在客戶端測試中，模擬工廠以返回虛假或樁物件。這可將客戶端邏輯與建立邏輯分離。
- 測試工廠： 獨立測試工廠，以確保其根據輸入參數返回正確的具體類型。
- 整合測試： 驗證具體工廠所建立的物件，是否根據產品介面正確運作。
🌐 實際應用場景
了解此模式的應用情境，有助於識別重構的機會。
UI框架
GUI工具包通常使用工廠模式來建立元件。工廠可根據作業系統（Windows、macOS、Linux）產生特定的按鈕、文字欄位或選單，而應用程式程式碼無需知道平台細節。
資料庫連線
連接資料庫的應用程式使用工廠來建立連線物件。工廠可根據設定選擇適當的驅動程式（SQL Server、Oracle、MySQL），使應用程式邏輯與資料庫無關。
記錄系統
記錄框架可能使用工廠來實例化不同的處理器（控制台、檔案、網路）。應用程式請求一個記錄器，工廠則根據環境提供正確的處理器。
🔮 未來導向的架構設計
設計時考慮可擴展性，對於長期維護至關重要。工廠模式透過允許系統成長，支援架構的演進。
- 外掛系統：工廠可以在執行時期動態載入外掛。
- 功能旗標：工廠可以根據功能旗標切換實作方式。
- A/B 測試：不同的工廠變體可以在不修改程式碼的情況下提供不同的使用者體驗。
🛑 何時不應使用工廠模式
有些情境下，此模式會帶來不必要的複雜性。
- 固定依賴：如果應用程式總是需要完全相同的類別，則工廠是多餘的。
- 簡單的指令碼：小型指令碼或一次性程式不需要多個介面和類別所帶來的額外負擔。
- 效能關鍵路徑：如果物件建立是瓶頸，工廠的間接性可能會增加無法接受的延遲。
📈 成功指標的衡量
要如何知道實作是否運作良好？請留意以下指標。
- 合併衝突減少：由於客戶端程式碼不參考具體類別，產品變更很少會在客戶端檔案中造成衝突。
- 程式碼變更更少：新增產品類型在整個程式碼庫中所需的程式碼變更更少。
- 提升可測試性：模擬變得更容易，進而提升程式碼覆蓋率，並增強重構時的信心。
- 更清晰的架構：關注點分離使得新成員更容易理解程式碼庫。
🎯 重點摘要
- 工廠模式封裝物件建立邏輯，以降低耦合度。
- 主要有三種變體：簡單工廠、工廠方法與抽象工廠。
- 根據複雜度與可擴充性需求選擇適當的變體。
- 將此模式與SOLID原則對齊，以實現穩健的設計。
- 避免使用複雜的工廠結構來過度設計簡單系統。
- 正確的測試策略對於驗證工廠行為至關重要。
透過正確實施工廠模式，開發人員可以建立能夠適應變化的系統。當需求演變時，初期在結構上的投入會帶來回報。這種方法促進了代碼庫的可維護性、可擴展性和可理解性，長期而言更加輕鬆。