談談壞味道（3）：Long Parameter List & Divergent Change

Mar. 24 10:52~12:00

 

Long Parameter List（過長參數列）

Long parameter list的問題在《Refactoring》書中有直接提到，包含：

• Hard to understand（難以理解）：想像一個有著8個參數的函數，要知道這些參數每一個在做什麼的就已經夠累人了的，更別說要把資料正確的傳入。
• Inconsistent（不一致）：有些函數需要類似的參數，當參數列過長的時候，開發人員可能會在不同的函數中以不同的順序來傳入這些類似的參數，導致不一致的介面設計。例如，有的函數傳入（…，X，Y，…），有些傳入（…，Y，X，…）。
• Difficult to use（難以使用）：因為過長參數列難以理解，甚至可能出現不一致的情況，因此對使用這些具有過長參數列函數的開發人員而言，也是一件苦差事。
• Interface change（介面改變）：有著過長參數列的函數，只要任何一個參數改變，或是需要增加新的參數，都會造成函數介面改變。

以上總結long parameter list之所以會是一個bad smell的原因（force）可歸類為：understandability、usability、modifiability這三點。

***

移除long parameter list壞味道的方法，在《Refactoring》書中提到可以套用Replace Parameter with Method、Preserve Whole Object、Introduce Parameter Object。

***

Divergent Change（發散式修改）

Divergent change直接翻譯成「不是那麼白的白話文」，意思是說「一個類別違反了Single Responsibility Principle（SRP）」，其結果就是「一個類別會因為多種不同的原因而造成其改變」。這是一種「責任耦合」的現象，這種耦合性造成的影響就是：

• Modifiability（修改性）：一個類別會因為多種原因而一直需要被修改，代表不必要的責任耦合或是說缺乏內聚力。例如，一個Account類別除了表達銀行帳戶以外，還需要負責將自己存入資料庫，以及輸出到印表機。因此，帳戶欄位改變、資料儲存方式改變、列印方式改變，都會造成這個Account改變。
• Understandability（可理解性）：責任耦合的類別比較不容易被理解，因為閱讀程式碼的人需要自行判斷哪些instance variable與method是被哪一種責任所使用。
• Testability（可測性）：責任耦合的類別其邏輯相較於單一責任的類別來的複雜，也比較不易測試。此外，因為有多種原因會造成同一類別不斷被修改，因此也增加了可能需要伴隨修改測試案例的機會。
• Reusability（重複使用性）：一個負擔太多責任的類別通常隱含它和所處的context有比較緊密的關聯性，因此也比較不容易在其他的context中被重複使用。

以上總結divergent change之所以會是一個bad smell的原因（force）可歸類為：modifiability、understandability、testability、usability這四點。

***

移除divergent change壞味道的方法，在《Refactoring》書中提到可以套用Extract Class。

***

友藏內心獨白：一樣的東西要用不同的名詞來解釋，果然是quality with a name。