Refactoring to Composed Method

 組合方法，一個簡單的重構實現。通俗的理解就是壓縮你的方法體，用一個個小方法來封裝（代碼層次的封裝！封裝無所不在阿！）。記得老大(Edward)在關於軟體複雜度測量之循環複雜度測量上就有這樣一個重構實現。
為啥我們需要這樣一個實現呢？我個人體會，應該也是最重要的原因就是“降低理解代碼的時間“。如果一個方法有著上百行的實現，這個方法理解起來，將是非常痛苦的，如過在加上些全域變數啥的就更加痛苦了！記不清楚那位大師人物說過，他寫的ruby代碼，從來不超過3行！

拿書中列子來說：public void add(Object element)
{
   if(!readOnly)
   {
       int newSize =  size + 1;
       if(newSize > element.length)
       {
           object[] newElements = new object[elements.length+10];
           for(int i=0;i<size;i++)
           {
               newElement[i] = elements[i];
           }    
           elements = newElements;
       }
       elements[size++] = element;
   }
}

這樣一個方法，不算很長，但是如果要你3秒內告訴我實現邏輯。如何？有難度，我想。
但是，如果我們把一些實現細節壓縮封裝。public void add(object element)
{
    if(readonly)
        return;
    if(atCapacity())
        grow();
    addElement(element);
}

現在呢？簡單了吧？如果每個小方法名字都那麼清晰易懂（假設用中文），1秒就能理解了！
這樣帶來的一個好處就是你的代碼容易被閱讀和理解，同時還避免了細節擾亂你的思路。

但是也有這樣一些問題？
效率會不會因為方法調用而降低阿？對於這點我們根本不需要考慮，一是編譯器可能已經多我們這些小方法作了內聯最佳化，二是效能即使有影響，也是非常小的。一般大的效能問題都出現在sql,io讀寫方面。

學會了組合方法，但是要提醒你一點，提取方法的時候特別要注意“代碼層次”問題。把同一層次的代碼平等處理，比如，都提取方法出來，或都原封不動！要平等。