🎯 什麼情境該想到我
當你「發現同一個模組（或類別）常常因為好幾種完全不同的原因而被修改」的時候——例如加一種新產品要改它、換一個資料庫也要改它。
⚙️ 怎麼用（步驟 / 公式）
這味道是什麼徵兆：一段程式碼理想上「只因一種原因而改」。當你為了不同理由一次次回到同一個地方修改，代表它把多個不相關的職責（不同變化軸）混在一起了。這與「霰彈式修改」正好相反：發散是「一個模組、多種變化原因」。
通常用哪些重構手法對治：
- 拆分階段（Split Phase）：若這兩種原因對應處理流程的不同階段（如先解析、再計算），把它們切成前後兩段。
- 搬移函式（Move Function）：把處理不同原因的函式搬去各自合適的模組。
- 提煉類別（Extract Class）：把每一種變化原因各自封裝成一個類別。
目標：讓每個處理某一種變化的情境都集中在單一模組裡。
🧪 我實際套用的紀錄
- （待填）
⚠️ 注意 / 什麼時候不適用
- 拆分要基於「真的會各自獨立變化」的職責，別為了教條把本來內聚的東西硬拆散。
- 若某種「變化原因」其實很少發生、也不複雜，維持現狀可能更簡單。
🔗 相關工具
- 霰彈式修改 Shotgun Surgery（本味道的對照面：一種變化散落多個模組）
- 過大類別 Large Class（職責太多常同時引發發散式變化）
- 重構