🎯 什麼情境該想到我
當你「同一件事有好幾種可以互換的做法，想在執行期挑一種來用、之後也能替換」的時候（例如不同的排序法、計費規則、壓縮/加密演算法、驗證策略），或想用組合來消掉「該用哪一種」的一長串條件分支。
⚙️ 怎麼用（步驟 / 公式）
意圖：定義一系列演算法，把每一個都封裝起來，並使它們可以互相替換。策略模式讓演算法可以獨立於使用它的客戶端而變化。
主要參與者 / 結構：
- Strategy（策略介面）：宣告所有具體策略共同的演算法介面。
- ConcreteStrategy（具體策略）：各自實作一種演算法。
- Context（環境）：持有一個 Strategy 參照，把工作委派給它；可在執行期抽換策略。
做法要點：
- 把「會變的那段演算法」抽成 Strategy 介面。
- 每一種做法實作成一個具體策略類別。
- Context 以組合方式持有某個策略，需要時呼叫它，不自己寫死用哪一種。
- 由外部（客戶端或設定）決定注入哪個策略，可執行期替換。
🧪 我實際套用的紀錄
- （待填）
⚠️ 注意 / 什麼時候不適用
- 客戶端得知道有哪些策略、各自差在哪，才選得對——把選擇的責任推給了呼叫端。
- 策略很少或幾乎不變時，直接寫死或用簡單條件即可，別為了模式增加物件。
- 結構與狀態模式非常像，別搞混：策略是「主動挑一種演算法」，狀態是「隨狀態自動切換並會自我轉換」。
🔗 相關工具
- 狀態模式 State（結構孿生但意圖不同，見上）
- 範本方法模式 Template Method（同樣讓步驟可變，但範本方法靠繼承、策略靠組合抽換整個演算法）
- 工具-優先組合而非繼承（策略正是「用組合換掉條件分支/子類爆炸」的代表）
- 工具-針對介面編程（Context 只依賴 Strategy 介面）
- 工具-封裝變化點（把「會變的演算法」封裝在策略後面）
- 設計模式