《重構》心得

買了本《重構》，粗略的看了第一遍，把一些要點記錄在印象筆記中了，發出來分享下。

 

首先是，代碼的壞味道：

Duplicated Code重複代碼

某些代碼重複出現，能夠抽象到一個新的函數中，或者抽象到父類上去。

 

Long Method過長函數

過長函數是指，一個函數裏面實現的功能太多，越長也就越難理解。

你須要將一個過長的函數分解成各類小函數，命名是關鍵。

 

Data Clumps數據泥團

函數的參數很是的多，調用也頻繁，其中一個參數被刪掉，其餘的參數就不是那麼有意義了。

能夠把這些參數抽到一個類裏面，直接傳這個類的對象就行了。

 

Large Class過大的類

一個類若是作太多的事情，就會致使內部有不少實例變量，重複代碼就會出現。

考慮如何把他們分解到小的類上面。

 

Long Parameter List過長的參數列

一個方法的參數太多會變得很噁心

考慮，若是能夠傳一個對象給函數，函數能夠經過這個對象得到到那些參數

 

Divergent Change發散式變化

若是須要修改或者添加不一樣的功能，須要修改不一樣的函數。

考慮如何把它們分到不一樣的類裏面。

 

Shotgun Surgery霰彈式修改

若是須要修改或者添加某個功能，須要修改好幾個地方

考慮把須要修改的地方集中到一個函數裏。

 

Feature Envy依戀情結

若是某個函數執行的時候調用了另外一個對象的大多數方法。

也許應該把這個方法移動到那個對象裏面去。

 

Primitive Obsession基本類型偏執

將一些基本類型組成的數據抽象成小對象，money啊，phone number之類

 

Switch Statement switch驚悚現身

減小使用switch，就是少在case裏面放太多的代碼，只讓它作出一個選擇返回一個狀態，而後具體的操做經過調用對象的函數來實現。 

 

Parallel Inheritance Hierarchies平行繼承體系

當你給一個類增長字段的時候，也要給另外一個類增長一樣的字段。

解決方法是，讓一個繼承體系的實例去引用另外一個集成體系的實例。

 

Lazy Class冗贅類

若是一個類所得不值其身價，就讓它消失

 

Speculative Generality誇誇其談將來性

沒有必要以「考慮到將來某天咱們必定要作這樣的事情」爲藉口作些沒必要要的事情。

 

過多的註釋

優良的代碼是能夠直接看就能明白它的做用，複雜的代碼才須要把每一步的做用都詳細的說明出來。

 

接下來是， 重構手法：

Extract Method（提煉函數）

從大方法中提煉出獨立的部分，函數的細粒度越小，一是提升了它的複用性，二是它被覆寫的時候更容易。

 

Inline Method（內聯函數）

當有時候一個函數過於簡短，裏面的內容可能就是作一個簡單的判斷就返回的話，能夠考慮去掉這個方法。

 

Inline Temp（內聯臨時變量）

把一些經過方法返回的變量換成那句方法的調用（query）。

 

Replace Temp with Query（以查詢取代臨時變量）

當某些臨時變量只被賦一次值的時候（能夠將變量聲明爲final，而後運行下看看是否只被賦值一次），就將這些臨時變量所有換成方法的調用（或者成爲query）。

 

Introduce Explaining Variable（引入解釋性變量）

當某些語句很是的複雜，而後返回一個boolean型，而後這條長長的語句直接丟進if裏判斷，這會致使難以理解，能夠引入解釋型變量isRight之類的，將這些變量放入if中會比較好理解。

 

Replace Data Value with Object（以對象取代數據值）

有些數據，好比電話號碼，若是僅僅用一個字符串存儲可能之後操做會很是困難，它可能須要多種顯示的形式，因此把看似簡單的數據包裝成對象會方便之後的操做。

 

Encapsulate Field（封裝字段）

將public的字段改爲private，並提供setter和getter

 

轉載不註明出處，被人趴了腫麼辦， http://www.cnblogs.com/kross/p/3512800.html