代碼壞味道之過長的參數列，代碼味道過長參數

代碼壞味道之過長的參數列，代碼味道過長參數
1.為什麼會出現過長的參數的函數呢？

出現過長的參數列，我們在編寫程式的時候職責劃分不清晰，一個函數做了太多的事情，可能會讓調用者傳入更多的參數進行功能的實現。第二函數封裝不合理，導致調用函數的內部變數成為封裝函數的參數。

2.當我們遇上了過長的參數函數怎麼辦？

當我們遇上了過長的參數列的函數有兩種方法來解決，第一，通過重載參數把程式中暫時不需要的函數的參數進行封裝，減少過長的參數列。第二，通過封裝參數列對象，在封裝的時候盡量將職責相近的參數放在一起，這樣做提高了封裝對象的內聚性。

3.怎樣避免在平時的編碼中出現過長的參數列？

那麼我們怎樣來避免我們在編碼中出現過長的參數列呢？在使用SSH或者Spring MVC的時候我們都會接觸到很多的O，我們可以將過長的參數列封裝成為一個資料轉送對象，這樣做即減少了參數列又提升了代碼 的重用性。

其次我們合理的封裝函數，我經常採用的方式就是編寫完成一個函數之後回過頭來看看這個函數的職責範圍，將多餘一個職責的函數進行剝離，讓每一個函數都只具有單一的一個職責，這樣做了之後，在需要封裝參數對象的時候就可以提煉出內聚性很高的代碼了。

什是代碼的壞味道

壞味道一般出自《重構》一書，例如，代碼重複，過長的函數，過大的類，過長的參數列等等。
 
為何要重構？這裡有7個原因

　　3、難以通過重構手法完成的設計改動　　通過重構，可以排除所有設計錯誤嗎？是否存在某些核心設計決策，無法以重構手法修改？在這個領域裡，我們的統計資料尚不完整。當然某些情況下我們可以很有效地重構，這常常令我們倍感驚訝，但的確也有難以重構的地方。比如說在一個項目中，我們很難（但還是有可能）將「無安全需求（no security requirements）情況下構造起來的系統」重構為「安全性良好的（good security）系統」。　　這種情況下我的辦法就是「先想象重構的情況」。考慮候選設計方案時，我會問自己：將某個設計重構為另一個設計的難度有多大？如果看上去很簡單，我就不必太擔心選擇是否得當，於是我就會選最簡單的設計，哪怕它不能覆蓋所有潛在需求也沒關係。但如果預先看不到簡單的重構辦法，我就會在設計上投入更多力氣。不過我發現，這種情況很少出現。　　4、何時不該重構？　　重寫（而非重構）的一個清楚訊號就是：現有代碼根本不能正常運作。你可能只是試著做點測試，然後就發現代碼中滿是錯誤，根本無法穩定運作。記住，重構之前，代碼必須起碼能夠在大部分情況下正常運作。　　一個折衷辦法就是：將「大塊頭軟體」重構為「封裝良好的小型組件」。然後你就可以逐一對組件作出「重構或重建」的決定。這是一個頗具希望的辦法，但我還沒有足夠資料，所以也無法寫出優秀的指導原則。對於一個重要的古老系統，這肯定會是一個很好的方向。　　另外，如果項目已近期限，你也應該避免重構。在此時機，從重構過程贏得的生產力只有在期限過後才能體現出來，而那個時候已經時不我予。Ward Cunningham對此有一個很好的看法。他把未完成的重構工作形容為「債務」。很多公司都需要借債來使自己更有效地運轉。但是借債就得付利息，過於複雜的代碼所造成的「維護和擴充的額外開銷」就是利息。你可以承受一定程度的利息，但如果利息太高你就會被壓垮。把債務管理好是很重要的，你應該隨時通過重構來償還一部分債務。　　如果項目已經非常接近期限，你不應該再分心於重構，因為已經沒有時間了。不過多重專案經驗顯示：重構的確能夠提高生產力。如果最後你沒有足夠時間，通常就表示你其實早該進行重構。　　代碼壞味道　　1、重複的代碼。　　如果你在一個以上的地點看到相同的程式結構，那麼可以肯定：設法將他們合二為一。　　2、過長的函數。　　越短的函數會存活的時間更長，存活的更好。　　3、過長的類。　　如果想利用單一的類做很多的事情，那麼該類的內部會出現很多的instance變數，重複代碼就要接踵而至了。　　4、過長的參數列。　　太長的參數列難以理解，太多的參數會造成前後不一致，不易使用，一旦你需要更多的資料，就不得不修改它。　　5、發散式變化。　　一旦我修改軟體，我希望只在一處修改就好，如果不能做到這點，該壞味道就出現了。　　6、煙霧彈式修改。　　一旦軟體進行修改，你必須去對多個類的內部做小修改，該壞味道出現了。　　函數對某個類的興趣高過對自己所處之host類的興趣，壞味道出現了。