[心得]打造可維護軟體05-讓程式碼單元的介面保持簡單

  • 356
  • 0

打造可維護軟體第五章-讓程式碼單元的介面保持簡單

讓程式碼單元的介面保持簡單的指導方針為:

限制每個程式碼單元(method)的參數不能超過4個

在程式人員的日常工作中,似乎經常無法避免用到大量的參數。長遠來看,大量參數會導致method難以維護和重利用。重構方法 - Introduce Parameter Object,就是用來保持介面簡單的方式。可以參考搞笑談軟工 :用Introduce Parameter Object移除Long Parameter List怪味道

介面簡短的方法能夠維持簡單的上下文,因而更容易被人理解。從某個意義來說,介面長短與程式碼單元(method)的尺寸和複雜度有關係。如果你的方法包含8個參數(舉例來說),以及處理8個參數的程式碼,你就很難將它拆分成多個獨立的部分。

冗長介面通常不是主要問題,而是真實問題的表徵-意味著糟糕透頂的資料模型

如何遵守此指導方針

介面應該簡短到甚麼程度?將參數個數上限設為 4 是比較合理的(作者沒有說為什麼)。

透過重構方法Introduce Parameter Object將參數包裝成參數物件(parameter object),或稱做DTO(data transfer object),這些物件實際上代表對應的Domain的重要概念。例如:一組點座標、一個矩形。封裝這些 類別並不只是減少方法參數的個數,還有可能將一些行為搬到該類別上,讓邏輯更集中更乾淨。

常見的反對意見

試著反向思考這個問題

參數物件具有龐大的介面

「我所引進之參數物件的建構式現在擁有太多參數」

如果遇到這種情況,通常意味著需要在該物件內部進行更細緻的劃分。

重構冗長介面並未改善我的情況

「在重構方法時,我還是把大量參數傳遞給另一個方法」

避免冗長介面並非總是一件容易的事,通常不單靠重構的某一個方法。作者建議,應該持續將不同職責拆分到各個方法去。

Framework或Library已經定義了具有冗長參數列的介面

「在我們正在使用的框架中,某些介面具有9個參數。如何在不違反介面指導方針的情況下實作它們呢?」

作者承認這是不容易的事,只能盡量限制住它們的衝擊。作者建議用Adapter Pattern去隔離它。