Quartz 5

Head First 設計模式 Head First Design Patterns

Properties1
tagssoftware, design-patterns, oop

2 min read

📌 30 秒摘要（Layer 3）

用大量圖解、故事、練習把 GoF 的設計模式講到「好懂又記得住」。但它真正的價值是把模式背後的設計原則提煉成一份清單——封裝變化、組合優於繼承、針對介面、鬆耦合、開閉原則、依賴反轉、好萊塢原則、最少知識。學會這些原則，你就能理解「為什麼」用某個模式，而不是死背 23 個。

🗺 心智圖（Canvas）

HeadFirst 設計模式

🐦 Head First 設計模式

學原則 > 背 23 個模式

工具-封裝變化點

🎯 什麼情境該想到我

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

⚙️ 怎麼用

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

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

🧪 我實際套用的紀錄

  • 2026-07-14：（待填）

⚠️ 注意

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

🔗 相關工具

找出會變的部分 把變動的部分抽離、封裝起來，讓其他不變的部分不受影響——所有模式的共同本質。

🎯 封裝變化（核心心法）

工具-優先組合而非繼承

🎯 什麼情境該想到我

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

⚙️ 怎麼用

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

🧪 我實際套用的紀錄

  • 2026-07-14：（待填）

⚠️ 注意

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

🔗 相關工具

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

🎯 什麼情境該想到我

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

⚙️ 怎麼用

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

🧪 我實際套用的紀錄

  • 2026-07-14：（待填）

⚠️ 注意

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

🔗 相關工具

🧩 組合與介面

鬆耦合 讓互動的物件之間所知越少越好（如 [[觀察者模式|Observer]]：主題只知道觀察者實作了某介面）。

最少知識原則（迪米特法則） 只和你的「密友」交談，別讓呼叫鏈穿透太多物件。

🔗 力求鬆耦合

工具-開閉原則

🎯 什麼情境該想到我

當你「每加一個新功能/新類型，就得回頭改一堆既有程式（還常改壞）」，或 if-else/switch 越加越長時。

⚙️ 怎麼用

對擴充開放，對修改關閉：新增行為靠「加新程式」，而不是「改舊程式」。

  1. 找出會不斷新增類型/行為的變化點。
  2. 抽成介面，讓既有流程依賴介面（見 工具-針對介面編程）。
  3. 新增功能＝新增一個實作類別，既有程式碼不動。
    • 例：新增付款方式＝加一個 PaymentMethod 實作，不改結帳流程。

🧪 我實際套用的紀錄

  • 2026-07-14：（待填）

⚠️ 注意

  • 不可能對「所有」變化都開放；只針對你判斷會反覆變的軸線設計（見 工具-封裝變化點），否則過度設計。

🔗 相關工具

工具-好萊塢原則與依賴反轉

🎯 什麼情境該想到我

當高層業務邏輯直接依賴低層細節（DB、第三方），導致底層一改就害到上層，或你想做「可插拔」架構時。

⚙️ 怎麼用

  1. 依賴反轉（DIP）：高層與低層都依賴抽象，別讓高層依賴具體低層。
  2. 好萊塢原則：「別打電話給我們，我們會打給你。」——由高層/框架決定何時呼叫低層元件，低層只實作被回呼的介面，不主動反向依賴高層。
  3. 效果：控制流與依賴方向解耦，低層變成可替換的外掛（框架、DI 容器都靠這個）。

🧪 我實際套用的紀錄

  • 2026-07-14：（待填）

⚠️ 注意

  • 抽象要放在「高層擁有、低層實作」的位置，別讓抽象反而綁死在低層。

🔗 相關工具

🚪 擴充性與依賴方向

懂原則就能推導模式 原則是「為什麼」，模式是「怎麼做」；先懂原則，模式自然浮現。

完整 23 模式定義 更正式的型錄與分類見 [[設計模式]]（GoF）。

📖 與 GoF 型錄的關係

Link to original

🧰 這本書給我的工具

（另有多個原則與 設計模式 共通：見 工具-封裝變化點、工具-針對介面編程、工具-優先組合而非繼承）

✨ 關鍵重點（Layer 1–2）

  • 設計原則清單：封裝變化、組合優於繼承、針對介面編程、力求鬆耦合、對擴充開放對修改關閉（OCP）、依賴抽象（DIP）、好萊塢原則、最少知識（迪米特）。
  • 鬆耦合：讓互動的物件之間所知越少越好（如 Observer）。
  • 學原則 > 背模式：懂原則就能自己推導出模式。

💬 金句原文（Layer 0）

  • 「別打電話給我們，我們會打給你。」（好萊塢原則）

🔗 相關

  • 完整模式目錄與更正式的定義見 設計模式（GoF）

Graph View

Backlinks