### Long Method（過長函數） 擁有[短函數」（short methods）的對象會活得比較好、比較長。不熟悉面向對象技術的人，常常覺得對象程序中只有無窮無盡的delegation（委托），根本沒有進行任何計算。和此類程序共同生活數年之后，你才會知道，這些小小函數有多大價值。「間接層」所能帶來的全部利益——解釋能力、共享能力、選擇能力——都是由小型函數支持的（請看p.61的「闖接層和重構」〕。 很久以前程序員就巳認識到：程序愈長愈難理解。早期的編程語言中，「子程序調用動作」需要額外開銷，這使得人們不太樂意使用small method。現代OO語言幾乎已經完全免除了進程（process）內的「函數調用動作額外開銷」。不過代碼閱讀者還是得多費力氣，因為他必須經常轉換上下文去看看子程序做了什么。某些開發環境允許用戶同時看到兩個函數，這可以幫助你省去部分麻煩，但是讓small method容易理解的真正關鍵在于一個好名字。如果你能給函數起個好名字，讀者就可以通過名字了解函數的作用，根本不必去看其中寫了些什么。 最終的效果是：你應該更積極進取地分解函數。我們遵循這樣一條原則：每當感覺需要以注釋來說明點什么的時候，我們就把需要說明的東西寫進一個獨立函數中，并以其用途（而非實現手法）命名。我們可以對一組或甚至短短一行代碼做這件事。哪怕替換后的函數調用動作比函數自身還長，只要函數名稱能夠解釋其用途，我們也該毫不猶豫地那么做。關鍵不在于函數的長度，而在于函數「做什么」和「如何做」之間的語義距離。 百分之九十九的場合里，要把函數變小，只需使用Extract Method。找到函數中適合集在一起的部分，將它們提煉出來形成一個新函數。 如果函數內有大量的參數和臨時變量，它們會對你的函數提煉形成阻礙。如果你嘗試運用Extract Method，最終就會把許多這些參數和臨時變量當作參數，傳遞給被提煉出來的新函數，導致可讀性幾乎沒有任何提升。啊是的，你可以經常運用Replace Temp with Query 來消除這些暫時元素。Introduce Parameter Object 和Preserve Whole Object 則可以將過長的參數列變得更簡潔一些。 如果你已經這么做了，仍然有太多臨時變量和參數，那就應該使出我們的殺手锏： Replace Method with Method Object。 如何確定該提煉哪一段代碼昵？ 一個很好的技巧是：尋找注釋。它們通常是指出「代碼用途和實現手法間的語義距離」的信號。如果代碼前方有一行注釋，就是在提醒 你：可以將這段代碼替換成一個函數，而且可以在注釋的基礎上給這個函數命名。就算只有一行代碼，如果它需要以注釋來說明，那也值得將它提煉到獨立函數去。 條件式和循環常常也是提煉的信號。你可以使用Decompose Conditional 處理條件式。至于循環，你應該將循環和其內的代碼提煉到一個獨立函數中。