設計模式：可復用物件導向軟體的基礎 Design Patterns (GoF)

📌 30 秒摘要（Layer 3）

把物件導向設計中反覆出現的問題，整理成 23 個有名字的解法（模式），分成創建型、結構型、行為型三類。但比模式本身更重要的是背後的兩條設計心法：針對介面編程，而非實作；優先使用物件組合，而非類別繼承。所有模式的本質，都是封裝變化——把會變的部分隔離起來。

🗺 心智圖（Canvas）

設計模式

🎨 設計模式 GoF

Design Patterns — 四人幫 本質：封裝變化

工具-針對介面編程

🎯 什麼情境該想到我

當你的程式碼「依賴具體類別」導致改一處動全身、難替換、難測試時。

⚙️ 怎麼用

1. 依賴抽象（介面/父型別），不依賴具體實作：呼叫端只認介面。
2. 物件的建立與使用分離：用工廠/注入取得具體實作，使用處不 new 具體類別。
3. 好處：實作可自由替換（換套件、換演算法）、可在測試中換測試替身。

🧪 我實際套用的紀錄

• 2026-07-14：（待填）

⚠️ 注意

• 別為了「未來也許會變」而到處加介面；在確有變化點或需要測試隔離時才抽（見 工具-封裝變化點）。

🔗 相關工具

• 工具-優先組合而非繼承 —— 常一起用，組合進來的東西是介面，換實作才不牽動使用端
• 工具-封裝變化點 —— 目的，介面是把變化藏起來最常用的那道牆
• 工具-打破依賴以便測試 —— 驗收方式，能不能塞測試替身進去，就是介面抽對沒有的檢查
• 工具-介面設計原則 —— 品質要求，介面本身設計不好，抽象只是換個地方糾纏

工具-優先組合而非繼承

🎯 什麼情境該想到我

當你在猶豫「用繼承還是組合來重用行為」，或繼承層級越來越深、改父類就牽連一堆子類時。

⚙️ 怎麼用

1. 重用行為時，先想「有一個」（組合）而非「是一個」（繼承）：把行為委派給組合進來的物件。
2. 繼承是編譯期綁死的白箱，組合是執行期可換的黑箱——組合更有彈性。
3. 用繼承前先確認是真正的 is-a 關係，且父類穩定。
4. 需要在執行期切換行為（如 Strategy 模式）→ 幾乎都用組合。

🧪 我實際套用的紀錄

• 2026-07-14：（待填）

⚠️ 注意

• 不是「禁用繼承」；穩定的 is-a、需要多型時繼承仍恰當。

🔗 相關工具

• 工具-針對介面編程 —— 組合的前置條件：被組合進來的東西要是介面，換實作才不會又改一輪
• 工具-封裝變化點 —— 為什麼組合會贏：把會變的部分抽成可替換的物件，正是組合的本質
• 工具-開閉原則 —— 目的地：組合＋介面是達成「加新功能不改舊程式」最常走的路徑

工具-封裝變化點

🎯 什麼情境該想到我

當某部分需求「經常改」、每次一改就要動很多地方，想把變化隔離起來時。這是所有設計模式的共同本質。

⚙️ 怎麼用

1. 找出「會變」與「不變」的部分：把兩者分開。
2. 把會變的部分抽成獨立元件（介面 + 可替換實作），讓不變的部分依賴抽象。
3. 未來需求變動只需新增/替換那個元件，不動其餘（呼應 工具-開閉原則）。

例：付款方式會變 → 抽出 PaymentMethod 介面，新增付款方式＝加一個實作。

🧪 我實際套用的紀錄

• 2026-07-14：（待填）

⚠️ 注意

• 只封裝「真的會變」的點；對不會變的東西加彈性＝過度設計、徒增複雜度。

🔗 相關工具

• 工具-針對介面編程 —— 封裝變化的落地方式，把會變的部分藏到介面後面
• 工具-優先組合而非繼承 —— 組裝方式，用組合替換變化的部分比用繼承覆寫更好抽換
• 工具-管理複雜度 —— 上位準則，封裝變化本質上是在降低要同時記住的東西

🧭 設計心法（先於模式）

🏗 創建型 Creational（5） 管「怎麼建立物件」 [[抽象工廠模式]]・[[建造者模式]]・[[工廠方法模式]]・[[原型模式]]・[[單例模式]]

🧩 結構型 Structural（7） 管「怎麼組合物件與類別」 [[配接器模式]]・[[橋接模式]]・[[組合模式]]・[[裝飾者模式]]・[[外觀模式]]・[[享元模式]]・[[代理模式]]

🔄 行為型 Behavioral（11） 管「物件間怎麼分工與溝通」 [[責任鏈模式]]・[[命令模式]]・[[直譯器模式]]・[[迭代器模式]]・[[中介者模式]]・[[備忘錄模式]]・[[觀察者模式]]・[[狀態模式]]・[[策略模式]]・[[範本方法模式]]・[[訪問者模式]]

📖 模式型錄（23）

[[策略模式|Strategy]] vs [[狀態模式|State]] 選演算法 vs 隨狀態換行為

[[裝飾者模式|Decorator]] vs [[代理模式|Proxy]] 加功能 vs 控制存取

[[配接器模式|Adapter]] vs [[橋接模式|Bridge]] 事後轉介面 vs 事前分離抽象與實作

⚖️ 容易混淆的孿生

Link to original

🧰 這本書給我的工具

設計心法（先於模式）

• 工具-針對介面編程 — 想降低耦合、讓實作可替換時
• 工具-優先組合而非繼承 — 在繼承與組合間抉擇時
• 工具-封裝變化點 — 設計時想預留變化彈性

🏗 創建型 Creational（5，管「怎麼建立物件」）

• 抽象工廠模式 Abstract Factory、建造者模式 Builder、工廠方法模式 Factory Method、原型模式 Prototype、單例模式 Singleton

🧩 結構型 Structural（7，管「怎麼組合物件與類別」）

• 配接器模式 Adapter、橋接模式 Bridge、組合模式 Composite、裝飾者模式 Decorator、外觀模式 Facade、享元模式 Flyweight、代理模式 Proxy

🔄 行為型 Behavioral（11，管「物件間怎麼分工與溝通」）

• 責任鏈模式 Chain of Responsibility、命令模式 Command、直譯器模式 Interpreter、迭代器模式 Iterator、中介者模式 Mediator、備忘錄模式 Memento、觀察者模式 Observer、狀態模式 State、策略模式 Strategy、範本方法模式 Template Method、訪問者模式 Visitor

✨ 關鍵重點（Layer 1–2）

• 三大類共 23 模式：創建型 5（Abstract Factory、Builder、Factory Method、Prototype、Singleton）、結構型 7（Adapter、Bridge、Composite、Decorator、Facade、Flyweight、Proxy）、行為型 11（Chain of Responsibility、Command、Interpreter、Iterator、Mediator、Memento、Observer、State、Strategy、Template Method、Visitor）。
• 兩條核心原則：針對介面編程、組合優於繼承。
• 共同本質：封裝變化——找出「會變的部分」把它隔離。
• 模式是「詞彙」：讓團隊用一個詞就溝通一整套設計。
• 幾組容易混淆的孿生：Strategy vs State（選演算法 vs 隨狀態換行為）、Decorator vs Proxy（加功能 vs 控制存取）、Adapter vs Bridge（事後轉介面 vs 事前分離抽象與實作）。

💬 金句原文（Layer 0）

• 「針對介面編程，而不是針對實作編程。」
• 「優先使用物件組合，而非類別繼承。」

🔗 相關

• 更好上手的教學版見 HeadFirst 設計模式（同樣的模式 + 設計原則）