1. 程式人生 > >Refactoring之——代碼的壞味道(四)過長參數列

Refactoring之——代碼的壞味道(四)過長參數列

每一個 頻繁 數列 發的 blog font 字段 代碼的壞味道 introduce

1.1.4 Long Parameter List(過長參數列)

特征:一個方法有超過三四個的參數。

技術分享

問題原因:

過長參數列可能是將多個算法並到一個函數中時發生的。函數中的入參可以用來控制最終選用哪個算法去執行。

過長參數列也可能是解耦類之間依賴關系時的副產品。例如,用於創建函數中所需的特定對象的代碼已從函數移動到調用函數的代碼處,但創建的對象是作為參數傳遞到函數中。因此,原始類不再知道對象之間的關系,並且依賴性也已經減少。但是如果創建的這些對象,每一個都將需要它自己的參數,這意味著過長參數列。

太長的參數列難以理解,太多參數會造成前後不一致、不易使用,而且一旦需要更多數據,就不得不修改它。

解決方法:

  • 檢查什麽值被傳入參數,如果向已有的對象發出一條請求就可以取代一個參數,那麽你應該使用 以函數取代參數(Replace Parameter with Methods) 。在這裏,“已有的對象”可能是函數所屬類裏的一個字段,也可能是另一個參數。
  • 你還可以運用 保持對象完整(Preserve Whole Object) 將來自同一對象的一堆數據收集起來,並以該對象替換它們。
  • 如果某些數據缺乏合理的對象歸屬,可使用 引入參數對象(Introduce Parameter Object) 為它們制造出一個“參數對象”。

技術分享

收獲:

  • 更易讀,更簡短的代碼。
  • 重構可能會暴露出之前未註意到的重復代碼。

何時忽略:

  • 這裏有一個重要的例外:有時候你明顯不想造成"被調用對象"與"較大對象"間的某種依賴關系。這時候將數據從對象中拆解出來單獨作為參數,也很合情理。但是請註意其所引發的代價。如果參數列太長或變化太頻繁,就需要重新考慮自己的依賴結構了。

Refactoring之——代碼的壞味道(四)過長參數列