本章主軸#

工廠（factory）並非設計上的小細節——它是讓使用方乾淨、讓修改集中、讓系統可長可久的核心元素。本章把工廠擺在新的位置：不只是「new 物件的方法」，而是物件管理者。

為什麼需要工廠？#

物件導向的世界裡，「使用」與「建立」是兩件不同的事。新手常把兩者混在一起：

• 程式碼一邊執行業務邏輯，一邊在 if-else 裡決定 new 哪個類別
• 結果：凝聚變弱，過早綁死在某種實例化策略

規則：先決定要什麼物件，再決定如何建立它們。

工廠正是把後半段獨立出來的場域。

什麼是工廠？#

任何用來實例化其他物件的東西——靜態方法、實例方法、整個物件——都算是工廠。GoF 把建立類模式列為一群：

• Abstract Factory
• Builder
• Factory Method
• Prototype
• Singleton

而本書還會額外帶入 Object Pool。

把工作切成兩組#

設想兩組人：

• A 組：定義物件、它們的職責、彼此如何協作
• B 組：負責根據情境實例化正確的物件、必要時管理共享或重用

問問自己：哪組人比較難？學生通常都答 A 組。

而 B 組為 A 組省下的工，遠超過 B 組自己的工作量。

因為 A 組擺脫了「哪個情境用哪個實作」的負擔，可以全心面向抽象。

工廠遵守哪些設計原則？#

• 強凝聚：A 與 B 各自只關心自己職責
• 鬆耦合：使用方完全不知有哪些具象類別存在
• 可測試：使用方對任何實作組合行為都一致，不必組合式測試
• OCP：要新增一個實作？多半只需改工廠

限制變動的擴散#

軟體要長久維護，重點在於讓改動只觸及該觸及的地方：

• 物件多有 N 個使用方，但通常只有一個工廠負責建立或管理它
• 改動集中在工廠 → 維護成本壓低
• 我們可以把「實例化」延後處理 → 設計時可以先享受彈性

工廠讓整合變便宜#

經驗法則：整合新程式碼進既有系統的成本，比新程式本身的開發成本還高。

工廠把情境資訊集中在少數幾個物件，新增情境只需新增一個小工廠 + 一組新類別，使用方完全不動。

工廠的角色不只限於 new#

• 哪個物件 → Abstract Factory
• 多少個物件 → Singleton、Object Pool
• 如何把 Decorator 鏈組起來 → 工廠把複雜度藏起來
• 錯誤處理 → 也可由工廠承擔

工廠某種意義上是在「收拾模式自己製造的問題」——模式為了可維護性引入了大量間接層，而工廠把這些間接層藏在使用方背後。

一條基本守則#

「物件要嘛使用其他物件，要嘛建立／管理其他物件，不能同時兩者。」

職責清楚分離 → 凝聚與封裝雙贏。

本章重點#

• 工廠的真正價值不是「new 物件」，而是讓使用方乾淨
• 把職責一刀切：A 用、B 造，整體更易維護、整合、測試
• 模式中的 Singleton、Abstract Factory、Object Pool、Factory Method 都是這個思想的不同面向
• 永遠記住：A 用 B，或 A 造 B，不能兩者皆是