PHP 雜談《重構-改善既有代碼的設計》之五 簡化函數調用PHP 雜談《重構-改善既有代碼的設計》之一 重新組織你的函數>

  思維導圖 

  介紹  　　前幾篇系列文章，我比較關注的是<PHP 雜談《重構-改善既有代碼的設計》之一 重新組織你的函數>，但是我覺得我還是沒有說清楚，我自己也有很多不理解的地方，而且這篇是我的第一篇這方面的文章，有很多的紕漏，所以我會經常性的去做修改，如果大家有好的意見不妨告知一、二。

  　　今天談得是“介面”，此介面非“Interface”，而是一個統稱。我們一般可以把供別人使用的函數或者url（一般是用於提供資料）叫介面。——可能還有別的意思，畢竟我現在還屬於“菜鳥”，如果有理解上的錯誤，請指正。 　　我們知道“容易被理解和被使用的介面”，是開發良好物件導向軟體的關鍵。——本文將介紹“使介面變得更簡潔易用”的重構手法。  題外話：　　 如果大家覺得我這篇文章太長，看起來麻煩的話，建議大家”就看圖片和粗體的文字“。 　　昨天，“old“博友給我留言，我以前也沒仔細考慮過，這次我也想了想。留言內容是：

　　我個人覺得，很多事情只有我們去關注過，才能知道它的價值。　　至於簡單，重構的目地也是為了簡單和易理解性。　　至於執著，我覺得在技術上，我們很多時候需要這種執著，即使你過後覺得你錯了，但是我們在這之間還是會有所收穫。我們只有經曆過很多次的磨合（這種磨合有正確的也有錯誤的），我們才能知道它的價值，我們才能收穫到我們需要的東西。　　至於利益，”Old“是不是指公司利益，恩，確實是，很多時候我們在編碼的過程中，需要趕進度，還有我們在重構中也會有一些錯誤出來，所以我的建議是，在開發之初，你就要在設計和重構中，不斷進行磨合，不要覺得浪費時間，很多時候，好的結構能加速你的開發。  專業術語 

 

 

 

 

 

 

  Rename Method  狀況：如果函數的名稱未能揭示函數的用途，那麼 修改函數名稱。 

動機：　　我極力提倡的一種編程風格就是將複雜的處理過程分解成小函數。但是如果小函數的命名不好，這會使你費勁周折卻弄不清楚這些小函數各自的用途。 　　 給函數命名的一個好辦法：考慮應該給這個函數寫上一句怎樣的注釋 -——>     想辦法將注釋變成函數的名稱。 　　起一個好名稱並不容易，需要經驗。——要想成為一個真正的編程高手，“起名稱”的水平至關重要。 　　如果你看到一個函數名稱不能很好的表達它的用途，應該馬上加以修改。   Example: 　　

 

 

 

  Add Parameter  狀況：某個函數需要從調用端得到更多的資訊，那麼 為此函數添加一個參數，讓該參數帶進函數所需資訊。  動機：　　1、Add Parameter 是一個很常用的重構手法。　　2、修改過的函數需要一些過去沒有的資訊，因此你需要給函數添加一個參數。　　3、除了Add Parameter外，只要有可能，其他選擇都比“Add Parameter”要好，因為有可能其他選擇不會增加參數列的長度。——過長的參數列會使程式員記不住那麼多參數。 

  Remove Parameter  狀況：函數本體不再需要某個參數，那麼 將該參數去除。 動機：　　1、參數指出函數資訊，不同參數代表不同意義。函數調用這必須為每一個參數操心該傳什麼東西進去。——如果不去掉參數，那就為每一次調用多費一份心。　　2、如果你發現有很多調用者，那麼為了不讓調用者操心，你可以這樣做，把要移除的參數設定為某個預設值（如null），這樣調用者只傳那些沒有預設值的參數。

 

  Separate Query from Modifier  狀況：如果某個函數既返回對象的狀態值，又修改（副作用）對象狀態（state），那麼 建立兩個不同的函數，其中一個負責查詢，另一個負責修改。

 

 Example:

  Parameterize Method  狀況：如果若干函數做了類似的工作，但在函數本體中包含了不同的值，那麼 建立單一函數，以參數表達那些不同的值。 動機：　　1、一般是因為有少數幾個值不同，所以建立了幾個相似的函數。　　2、分離的函數替換為一個統一的函數，通過參數來處理那些變化情況，以簡化問題。　　3、去除重複的代碼，提高靈活性。——可以使用這個參數處理其他變化情況。

  Example：

  Replace Parameter with Explicit Methods  狀況：你有一個函數，其內完全取決於參數值而採取不同的反應，那麼 針對該參數的每個值，建立一個獨立的函數。動機：　　1、如果某個參數有離散值，而函數內又以條件式檢查這些參數值，並根據不同的參數值做出不同的反應，那麼就應該使用本次重構。　　2、可以獲得好處：“編譯期代碼檢查”，“介面更清楚”（如果用參數值決定函數行為，那麼函數使用者不但需要觀察該函數，而且還要判斷參數是否“合法化”。——而合法的參數，很少在文檔中提到，必須通過上下文，才能判斷）　　3、不考慮“編譯期檢驗”的好處，為了擷取一個清晰的介面，我們也值得這麼做。

 

Example:

 

  Preserve Whole Object  狀況：如果你從某個對象中取出若干值，將它們作為某一次函數調用中的參數，那麼 改使用（傳遞）整個對象。 動機：　　1、參數列更穩固;　　2、提高代碼的可讀性;——過長的參數列很難使用，因為調用者和被調用者都必須記住這些參數的用途。

Example：

  Replace Parameter with Methods  狀況：如果對象調用某個函數，並將所得結果做為參數，傳遞給另一個函數（接受參數的函數也有調用前一個函數的能力），那麼 讓參數接受者去除該項參數，並直接調用前一個函數。  動機：　　1、如果函數通過其他途徑獲得參數值，那麼它就不應該通過參數取得該值。　　2、過長的參數列會增加程式閱讀者的理解難度，因此我們應該儘可能的縮短參數列的長度。　　3、方法：看看“參數接受端”是否可以通過“與調用端相同的計算”來取得參數攜帶值。　　4、如果函數調用端通過對象內部的另一個函數來計算參數，並在計算過程中“未曾引用調用端的其他參數”，那麼就可以將這個計算過程轉移到被調用端內，從而去除該項參數。  Example：

  Introduce Parameter Object  狀況：某些參數總是很自然地同時出現，那麼 以一個對象取代這些參數。  動機：

　　1、一組參數可能有幾個函數同時使用，這些函數可能隸屬於同一個class，也可能隸屬於不同的classes。——這樣的一組參數就是所謂的Data Clump（資料泥團）。　　2、我們可以運用一個對象封裝所有這些資料，再以對象取代Data Clump。——目地：哪怕只是為了把這些資料群組織在一起，這樣做也是值得的。　　3、本項重構的價值在於“縮短了參數列的長度”。此外，新對象所定義的訪問函數（accessors）還可以使代碼更具一致性。——這又進一步降低了代碼的理解難度和修改難度。　　4、本項重構還可以帶給你更多好處。——當你把這些參數組織到一起之後，往往很快可以發現“可被移植建立class“的行為。——減少重複代碼。 Example： 

  Remove Setting Method  狀況：你的class中的某個範圍，應該在對象初創時被設定，然後就不再改變，那麼 去掉該範圍的所有設定函數（setter）。

動機：　　1、如果你為某個範圍提供了設定函數（setter），這就暗示了這個範圍可以被改變。　　2、如果你不希望在對象初創之後，此範圍還有機會改變，那就不要為它提供設定函數。——這樣你的意圖會更加清晰，並且可以排除其值被修改的可能性。 Example：

  Hide Method   狀況：如有有一個函數，從來沒有被其他class用到，那麼 將這個函數設定為private。  動機：

　　1、重構往往促使你修改“函數的可見度“。——時刻檢查可被隱藏的函數。　　  2、經常檢查有沒有可能降低某個函數的可見度（使它私人化）。　　　　——>當你在另一個class中移除對某個函數的調用時，就應該檢查。　　　　——>特別對setter函數進行上述的檢查。 　　 Replace Constructor with Factory Method 狀況：如果你希望在建立對象時不僅僅是對它做簡單的構件動作，那麼將__construct（建構函式）替換為factory method。
動機：
　　在subclass過程中以factory method取代type code。——你可能常常需要type code建立相應的對象。
 Example：

            

            

接著來：

 

  Replace Error Code with Exception  狀況：如果某個函數返回一個特定的代碼（special code），用以表示某種錯誤情況，那麼 改用異常（Exception）。  動機：　　清楚的將”普通程式“和”錯誤處理“分開，這使的程式更容易”理解“。

Example：

  conclusion 把我每一次的收穫與大家分享，如果大家有那麼一丁點的收穫，也讓我高興不已。還有如在文章中有錯誤，望請指點一、二。 我不知道是不是找錯地方了，有博友留言說“部落格園裡主要盛行C#”，看得人是不是主要以PHP程式員為主？還有很少有人給我留言，也很少有人指出我文章中的錯誤（難道我的文章中真的沒有錯誤嗎？），昨天”@四眼蒙面俠“給我留了言，我在與他的交談中收穫甚多，也感謝的他的批評指正，也希望能跟大家多交流。