🎯 什麼情境該想到我
當你「呼叫一個函式時要傳一長串參數，得反覆對照才知道每個位置是什麼」的時候——參數列變成理解與使用的負擔。
⚙️ 怎麼用（步驟 / 公式）
這味道是什麼徵兆：過長的參數列難記、易傳錯順序，還常暗示這些資料本該被組織成一個概念，或函式承擔了太多不該由呼叫端提供的東西。
通常用哪些重構手法對治：
- 引入參數物件（Introduce Parameter Object）：把總是一起出現的幾個參數包成一個物件。
- 保持物件完整（Preserve Whole Object）：與其從物件拆出幾個值再傳進去，不如直接傳整個物件。
- 以查詢取代參數（Replace Parameter with Query）：若某參數能由函式內部或別的參數推導出來，就別要求呼叫端傳。
- 用**函式組合成類別（Combine Functions into Class）**把共同參數變成欄位。
🧪 我實際套用的紀錄
- （待填）
⚠️ 注意 / 什麼時候不適用
- 「保持物件完整」與「以查詢取代參數」會讓函式依賴整個物件或內部狀態；若你刻意想降低函式與該物件的耦合（例如要保持純函式、方便測試），反而該保留明確的參數。
- 參數本身彼此獨立、數量合理時，攤平列出比硬包成物件更清楚。
🔗 相關工具
- 資料泥團 Data Clumps（總是成群的參數，正是引入參數物件的訊號）
- 基本型別偏執 Primitive Obsession（一串基本型別參數常可換成領域物件）
- 過長函式 Long Function（縮短函式時別讓參數列跟著膨脹）
- 重構