代碼的壞味道
1、重復的代碼(duplicated code)
 最單純的重復代碼就是，同一個class內的兩個函數含有相同的表達式。此時需要使用Extract Method，提煉出重復的代碼，然后讓這兩個地方都調用被提煉出來的那一段代碼。
另一種情況就是，兩個兄弟子類中含有相同的表達式。在這種情況下，只要對兩個子類都使用Extract Method，然后再對提煉出來的代碼使用pull up method將它推入超類中。如果代碼之間只是類似，并非完全相同，那么就使用Extract Method把相似部分和差異部分分割開，構成單獨一個函數，然后就能夠使用form template method獲得一個template method設計模式.

---

下面跳到后面去看一下template method：
將各個措施放到獨立的函數中，并保持它們具有相同的簽名式，原函數也就變得相同了。然后將原函數上移到superclass。
下面是仿照書中寫的例子。首先是Site類
現在有兩個類LifelineSite和ResidentialSite分別繼承自Site類并實現了方法GetBillAbleAmount
LifelineSite：
ResidentialSite：
現在使用template method進行重構：
首先重構類Site：
然后重構ResidentialSite：
最后重構LifelineSite：
可以看到，通過重構首先分離了計算BaseAmount和計算TaxAmount的兩個方法，然后把加和運算移動到超類Site中。GetTaxAmount由于代碼中存在近似的地方，將更加通用一些的步驟移動到超類中，在子類中的重復部分調用超類中的方法，然后子類各自對超類方法進行一些修飾來達到自己的運算目的。

---

2、Long Method（過長函數）
“間接層”所能帶來的全部利益--解釋能力、共享能力、選擇能力--都是由小型函數支持的。
讓small method容易理解的真正關鍵在于一個好名字。如果你能給函數起個好名字，讀者就可以通過名字了解函數的作用，根本不必去看其中寫了些什么。
最終的效果是：你應該更積極進取的分解函數，我們遵循這樣一條原則：每當感覺需要以注釋來說明點什么的時候，我們就把需要說明的東西寫進一個獨立的函數中，并以其用途（而非實現手法）命名。我們可以對一組或者甚至短短一行代碼做這件事。哪怕替換后的函數調用動作比函數本身還長，只要函數名稱能夠解釋其用途，我們也該毫不猶豫地那么做。關鍵不在于函數的長度，而在于函數“做什么”和“如何做”之間的語義距離。
百分之九十的場合里，要把函數變小，只需要Extract Method。找到函數中適合集中在一起的部分，將它們提煉出來形成一個新函數。
如果函數內有大量的參數和臨時變量，他們會對你的函數提煉形成阻礙。如果你嘗試用Extract Method，最終就會把許多這些參數和臨時變量當作參數，傳遞給被提煉出來的新函數，導致可讀性幾乎沒有任何提升。可以消除臨時元素的方法有：
Replace Temp with Query；
Introduce Parameter Object；
Preserve Whole Objet；
確定該提煉哪一段代碼的很好的技巧就是：尋找注釋。他們通常是指出“代碼用途和實現手法間的語義距離”的信號。如果代碼前方有一行注釋，就是在提醒你：可以將這段代碼替換成一個函數。而且可以在注釋基礎上給這個函數命名。條件式循環也常常是提煉的信號。你可以使用Decompose Conditional處理條件式。至于循環，你應該將循環和其內的代碼提煉到一個獨立函數中。