關於重構，代碼的壞味道，應該重構的代碼

應該重構的代碼

1.重複的代碼：

重複代碼在同一個類中的不一樣方法中，則直接提煉爲一個方法

若是重複代碼在兩個互爲兄弟的子類中，則將重複的代碼提到父類中

若是代碼相似，則將相同部分構成單獨函數，或者用 Template Method 設計模式

重複代碼出如今不相干的類中，則將代碼提煉成函數或者放在獨立的類中 

2.過長的函數：

下降了可讀性，應該將獨立的功能提煉成新函數

3. 過大類

使得責任不清晰，容易形成重複代碼，混亂，應該將過大類的功能拆分紅多個功能單一的小類

4.過長的參數列

過長的參數列難以理解，並且容易傳錯參數。應該將參數列表用參數對象替換

5.發散式變化：

一個類因爲不一樣的緣由而被修改。應該將類拆分紅多個，每一個類只由於一種變化而修改。

6.霰彈式修改：

 與發散式變化相反，遇到變化時須要修改許多不一樣的類。應該將相似的功能放到一個類中

7.依戀情結：

函數對某個類的興趣高過對本身所處的類，一般是爲了取其餘類中的數據。應該將函數部分功能移到它感興趣的類中

8.數據泥團：

在多個地方看到相同的數據項。例如：

      多個類中相同的變量，多個函數中相同的參數列表，而且這些數據老是一塊兒出現。應該將這些數據項放到獨立的類中

9.基本類別偏執：

對象技術的新手一般不緣由在小任務上運用小對象，好比結合數值和幣別的money class，等，應該Replace Data Value with Object。

10.分支語句：

大量的分支、條件語句致使過長的函數，而且可讀性差。應將它變成子類或者使用 State和 Strategy模式

11.平行繼承體系

是霰彈式修改的特殊狀況。通常是當你爲某個類增長了一個子類，必須也爲另外一個類相應的增長一個子類。若是你發現某個繼承體系的class名稱前綴和另外一個繼承體系的class名稱前綴徹底相同。變素有問題了。 應該讓一個繼承體系的實體（instance）指涉（參考，引用，refer to）另外一個繼承體系的實體。

12 冗贅類（lazy class）

幾乎沒有用的組建 應該進行inline class

13.誇誇其談將來性

如今用不到，以爲將來能夠用到的代碼，要警戒。應該將用不上的代碼去掉

14.過分耦合的消息鏈

 一個對象請求另外一個對象，後者又請求另外的對象，而後繼續。。。。，造成耦合的消息鏈。應該公佈委託對象供調用

15 純粹的數據類

  將數據類中數據以Public方式公佈，沒對數據訪問進行保護。應該 將數據封裝起來，提供Get/Set方法。

16 過多的註釋

 代碼有着長長的註釋，但註釋之因此可能是由於代碼很糟糕。先重構代碼，再寫上必要的註釋

17 使人迷惑的暫時值域

如某個instance變量僅爲某特定狀況而設，在變量未被使用的狀況下猜想當初設置目的很是困難。應該創建一個新的class，把全部和這個變量相關的代碼都放到裏面。

l

待續。。