多參數方法的問題

相信很多人曾經都寫過多參數的構造方法，就像下面示例的代碼。

當想要創建一個給全部屬性賦值的實例的時候，就會利用這個多參數的構造方法。但是，當類的屬性特別多的時候，你還會這么寫嗎？

如果你寫了一個包含N個參數的多參數構造方法，當創建實例的時候，是不是特別謹慎的在大腦里記著第幾個參數是給哪個屬性賦值的，生怕給弄錯了，當然類型不對的時候，編譯器還會友善的提醒賦值錯了，但對那些類型相同的屬性，如果不小心顛倒了兩個參數的順序，編譯器也愛莫能助了，程序運行起來也不會報錯，就是執行結果不是期望值。

如果有人寫了一個包含N個參數的多參數構造方法并打包后提供給你使用，又如果你看不到方法的源代碼或Javadoc，更不巧這些參數的名稱很隨意(例如arg1、arg2...argN等)，你會不會惡狠狠的在背后慰問代碼的作者。

這種多參數的構造方法，當參數的個數小于等于3的時候不是很糟糕，但是，隨著參數個數越來越多的時候，這種構造實例的方法就會失去控制，變得難以使用。

看到這里，也許有人會說，當然不會寫一個包含N個參數的多參數構造方法，可以使用默認的構造方法創建實例，然后使用setter方法給各個屬性一一賦值，就像下面示例代碼這樣。

不得不說這種方式創建實例很容易，產生的代碼也易讀，同時也是使用最頻繁的方式。但是，它有很嚴重的缺點，就是一旦提供了屬性的setter方法，則代表你可以在任何地方、任何時候給某個或某些屬性單獨賦值，致使實例的構造被分散到各個角落，最終可能會導致連代碼原作者都不知道在哪里給某個屬性“又”賦了值，導致實例數據不一致，調試查找問題也很麻煩。

這里筆者分享一個曾經經歷的，使用setter方法給屬性賦值的坑。很早之前使用Hibernate進行CRUD操作，大家都知道Hibernate的get和load方法查詢出的實體對象會被緩存，并且是處于持久態的，持久態的實體無論你顯示調用update操作或不調用，只要它在一個事務中，當事務被提交的時候，它會比較緩存中實體數據和快照區中的實體數據，將變化主動更新到數據庫中，坑就出現在這里。查詢出來的實體對象被當做參數傳遞到了其它方法中，而此時為了某些操作的需要，調用了某個屬性的setter方法賦值，但是并沒有顯示調用update方法，導致看上去每次執行完查詢數據就被自動更新，查找原因起來不是很容易。這就是使用setter方法導致的賦值分散的問題。

相信大多數人都寫過或使用過多參數的普通方法，就像下面示例的代碼。

可能會有人覺得這沒什么，不就5個參數嘛！沒事，就這么寫！對于這種覺悟，筆者只能說你試試10個參數或更多，保證你會精神崩潰，即使你能忍受，調用你方法的同事保證會在背后慰問你。

這種寫法也同樣有上面多參數構造方法的問題，參數多了方法就會失去控制，難以使用。

多參數方法指南

對于多參數的構造方法，使用Builder模式代替，就像下面的示例代碼。

從實例代碼可以看到，使用Builder模式構造實例根本不需要費盡心思的牢記參數列表，想給哪個屬性賦值直接顯示的給哪個屬性賦值，再也不怕賦錯值，代碼清晰明了！注意看示例代碼中，實際給bank實例屬性賦值的地方，即下面的代碼。

可以看到在Bank的構造方法里集中給各個屬性賦值，并不會分散賦值。如果想再次給某個屬性賦值，可以像示例代碼這樣。

對于普通方法，如果方法參數的個數大于三，將這些參數抽象成一個類，這些參數就是類的屬性，然后在多參數的方法中，使用這個類代替這些參數，同時在這個參數類中提供Builder模式代碼用于創建類的實例，就像下面的示例代碼。

總結

以上是生活随笔為你收集整理的java多参方法_Java中多参数方法进阶的全部內容，希望文章能夠幫你解決所遇到的問題。

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