作用

有助于設計易于學習和使用的API。

如何做——謹慎地選擇方法的名稱

1.選擇易于理解的，并且與同一個包中的其他名稱風格一致的名稱。

2.選擇與大眾認可的名稱相一致的名稱。

如何做——不要過于追求提供便利的方法

每個方法都應該盡其所能。

方法太多會使類難以學習、使用、文檔化、測試和維護。

只有當一項操作被經常用到的時候，才考慮為它提供快捷方法。

如果不能肯定，還是不提供快捷方法為好。

如何做——避免過長的參數列表

目標是四個參數以內。

相同類型的長參數序列格外有害。

避免過長的參數列表——把方法分解成多個方法，每個方法只需要這些參數的一個子集

注意提升分解出的多個方法的正交性。

避免過長的參數列表——創建輔助類(helper class)，用來保存參數的分組

如果一個頻繁出現的參數序列可以被看作是代表了某個獨特的實體，建議使用這種方法。

避免過長的參數列表——從對象構建到方法調用都采用Builder模式

如果方法帶有多個參數，尤其是當它們中有些是可選的時候，最好定義一個對象來表示所有參數，并允許客戶端在這個對象上進行多次“setter”調用，每次調用都設置一個參數，或者設置一個較小的相關的集合。

一旦設置了需要的參數，客戶端就調用對象的“執行(execute)”方法，它對參數進行最終的有效性檢查，并執行實際的計算。

其他建議

優先使用接口而不是類定義參數類型。

對于boolean參數，要優先使用兩個元素的枚舉類型。

Thermometer.newInstance(TemperatureScala.CELSIUS)比Thermometer.newInstance(true)更有用，而且支持在未來對TemperatureScala對進行擴展。

枚舉是可以有方法的，有時候這個特性也非常有用。

總結

以上是生活随笔為你收集整理的java已被弱化签名,高效Java第四十条建议：谨慎设计方法签名的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。