程序師世界是廣大編程愛好者互助、分享、學習的平台,程序師世界有你更精彩!
首頁
編程語言
C語言|JAVA編程
Python編程
網頁編程
ASP編程|PHP編程
JSP編程
數據庫知識
MYSQL數據庫|SqlServer數據庫
Oracle數據庫|DB2數據庫
 程式師世界 >> 編程語言 >> 網頁編程 >> PHP編程 >> PHP綜合 >> PHP 雜談《重構-改善既有代碼的設計》之五 簡化函數調用

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程序員為主?還有很少有人給我留言,也很少有人指出我文章中的錯誤(難道我的文章中真的沒有錯誤嗎?),昨天”@四眼蒙面俠“給我留了言,我在與他的交談中收獲甚多,也感謝的他的批評指正,也希望能跟大家多交流。
  1. 上一頁:
  2. 下一頁:
Copyright © 程式師世界 All Rights Reserved