思維導圖
介紹
前幾篇系列文章，我比較關注的是<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程序員為主？還有很少有人給我留言，也很少有人指出我文章中的錯誤（難道我的文章中真的沒有錯誤嗎？），昨天”@四眼蒙面俠“給我留了言，我在與他的交談中收獲甚多，也感謝的他的批評指正，也希望能跟大家多交流。
