🎨 設計模式 GoF

🎯 什麼情境該想到我

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

⚙️ 怎麼用

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：（待填）

⚠️ 注意

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

🔗 相關工具

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