多參數(shù)方法的問題

相信很多人曾經(jīng)都寫過多參數(shù)的構(gòu)造方法，就像下面示例的代碼。

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

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

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

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

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

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

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

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

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

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

多參數(shù)方法指南

對于多參數(shù)的構(gòu)造方法，使用Builder模式代替，就像下面的示例代碼。

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

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

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

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。