使用一種方法與常量作爲參數與幾種方法

在Kent Beck的Implementation Patterns，人們可以閱讀使用一種方法與常量作爲參數與幾種方法

「的常量的一個常見用途是通信在的接口的消息的變化。例如，爲了中心文字，你可以調用 setJustification(Justification.CENTERED)。這種風格API的一個優點是，你可以通過添加新常數不破壞實現者加現有方法的新變種。然而，日對於每個變體，ese消息不通信以及具有單獨的方法。在這種風格，上面的消息將是 justifyCentered()。一個界面，的方法的所有調用具有字面常量作爲參數傳遞，可以通過給它獨立的方法每個恆定值的提高。」

這是爲什麼呢？一般來說，當我編碼，我注意到我有幾個類似的參的方法，可以在下面的例子中可以減少到只有一個，有一個參數，比如，

void justifyRight() 
void justifyLeft() 
void justifyCentered()

我通常會做什麼肯特建議剛好相反，這將是將其分組爲

setJustification(Justification justification)

您通常如何處理這種情況？這是完全主觀的還是有非常強烈的理由，我不贊成肯特對此事的看法？

謝謝

來源

2010-07-24 devoured elysium

可能是一個社區維基... – pascal 2010-07-24 08:37:03

我認爲它的老派編程，當你試圖通過代碼重複獲得更好的性能。之後，當您需要向邊界類（包括左側，右側，底部，頂部邊距的大小）添加另一個參數時，最終會出現大量代碼重複。 – IAdapter 2010-07-24 09:03:21

我不認爲它與表現有關（至少與本書/作者有關）。 – 2010-07-24 09:30:05

文件訪問方式通常具有讀/寫模式參數，是否創建不存在的文件，安全屬性，鎖定模式等。想象一下，如果您要爲每個參數的有效組合創建一個單獨的方法，您將擁有多少方法！

我強調了支持單獨方法的最大論據;它是安全的，因爲你對API有嚴格的控制。如果您不公開這些參數，則調用方無法傳遞無效參數或無效參數組合。這也意味着較不復雜的參數驗證。

但是，我不贊成這種做法。 API的設計應該很好，應該是change as little as possible。Kent Beck關於破壞API更改：

[參數化方法]的一個優點是您可以通過添加新常量來添加新變體，而不會中斷實現者。

他贊成單獨的方法的說法是：

然而，[參數化方法]不溝通，以及具有針對每個變化的單獨的方法。

我不同意。方法參數可以一樣可讀。特別是與命名參數相結合，這是一種由多種語言支持的功能。此外，單獨的方法會導致混亂的API。

來源

2010-07-24 19:22:38

我想這是主觀的。有些人可能會認爲justifyLeft比明確的更合理（Justification.LEFT）將它摺疊到一個方法可能會導致更好的API - 更少的混亂 - 並且模式可以存儲在一個變量中，並簡單地將其提供給單個setXY方法（與每種方法都有不同的方法，您必須根據手動值決定要調用哪個方法）。所以我通常更喜歡這種方式。雖然它通常只是：

void justify(Justification justification) { 
    switch(justification) { 
     Justification.RIGHT: this.justifyRight(); 
     Justification.LEFT: this.justifyLeft(); 
     Justification.CENTERED: this.justifyCenter(); 
    } 
}

的時候當然是非常密切的關係所有這些方法，這是唯一可取的。

來源

2010-07-24 09:12:42 delnan

使用一種方法與常量作爲參數與幾種方法

回答

相關問題