何時進行重構

重構可遵循三次法則：第一次做某件事時只管去做；第二次做類似的事會產生反感，但無論如何還是可以去做；第三次再做類似的事，你就應該重構，即 事不過三，三則重構。具體表現為：添加功能時重構、修補錯誤時重構、復審代碼時重構。

對于現有代碼根本無法正常運作、項目已近最后期限的場景不能進行重構，前者可以考慮拆分后重寫，后者則是為了保證項目能正常上線。

具有哪些代碼特征需要重構

2.1 Duplicated Code (重復代碼)

如果你在一個以上的地點看到相同的程序結構，可以考慮設法將他們合而為一。

一般表現為：同一個類的兩個函數含有相同的表達式；兩個互為兄弟的子類內含有相同表達式；不同類中由于某種原因存在相同的或相似的表達式。

2.2 Long Method (過長函數)

如果一個函數超過了 50-80 行，你就可以考慮進行分解了。

一般從以下幾點入手：分析臨時變量和參數，考慮將注釋部分封裝到一個方法中，對于多個條件表達式和循環的部分進行封裝。

2.3 Large Class (過大的類)

如果一個類有太多實例變量和函數，可以考慮將幾個變量一起提煉到新類中，對于特征相似的函數可以考慮提煉到一個接口中，然后再針對不同接口分解這個類，拆分成多個實現類。

2.4 Long Parameter List (過長參數列)

如果函數的傳參太多導致難以理解，且對于調用方造成了困擾，就應該考慮縮減了，最好函數的傳參不要超過 10 個，如果太多可以考慮是否可以將傳參封裝到一個對象來進行傳遞。

2.5 Divergent Change (發散式變化) / Shotgun Surgery (霰彈式修改)

如果在修改程序某個功能時，需要修改多處地方，此時就應該考慮來重構它了，使該修改盡可能的集中在一個地方，便于后期維護。

2.6 Feature Envy (依戀情結)

如果某個類的函數為了計算某個值或其他行為需要從另一個對象那兒調用許多取值函數，此時就需要判斷哪個類擁有最多被此函數使用的數據，然后就把這個函數和那些數據擺在一起。

最根本的原則：將總是一起變化的東西放在一起，數據和引用這些數據的行為總是一起變化的，如果出現例外，我們就搬移那些行為，保持變化只在一地發生。

2.7 Data Clumps (數據泥團)

如果兩個類中相同的字段、許多函數簽名中相同的參數出現三四項，此時就需要將這些字段/參數刪除縮短，減少字段和參數的個數，提煉到一個獨立對象中。

2.8 Primitive Obsession (基本類型偏執)

所謂的基本類型偏執就是：對于對象和基本類型的取舍，如果多個基本類型字段總被放在一起使用的話，那么可以考慮將其定義為一個對象來進行使用了。

2.9 Switch Statement ( switch 驚悚現身)

少用 switch (或 case )語句，因為會出現許多重復，每當看到 switch 語句，如果條件語句很復雜，你就應該考慮使用多態來替換它。

2.10 Parallel Inheritance Hierarchies (平行繼承體系)

如果你發現某個繼承體系的類名稱前綴和另一個集成體系的類名稱前綴完全相同，即如果你為某個類增加一個子類，必須也為另一個類相應的增加一個子類，此時應該考慮重構了。消除這種重復性的一般策略是：讓一個繼承體系的實例引用另一個繼承體系的實例。

2.11 Lazy Class (冗贅類) / Speculative Generality (夸夸其談未來性)

如果一個類的所得不值其身價，它就應該消失。

如果一個類本應該做某事卻試圖以各式各樣的鉤子和特殊情況來處理一些非必要的事情，那么就應該考慮移除它；比如抽象類沒有太多作用的話就除掉，如果函數的參數未用到就應該去掉，如果函數或類的唯一用戶是測試用例，就應該去掉等。

2.12 Temporary Filed (令人迷惑的暫時字段)

如果某個實例變量僅為某種特定場景而定或者一個類中有個復雜算法，需要好幾個變量，但是這些字段只在該算法時才有效，其他情況下只會讓人迷惑，此時應該考慮將這些變量和其相關函數提煉到一個獨立類中，提煉后的新對象將是一個函數對象。

2.13 Message Chains (過度耦合的消息鏈)

如果一個對象請求另一個對象，然后再向后者請求另一個對象，然后在請求另一個對象，這就是消息鏈。通常最好的選擇是：先觀察消息鏈最終得到的對象是用來干什么的，看看能夠把使用該對象的代碼提煉到一個獨立函數中，把這個函數推入到消息鏈。

總結

以上是生活随笔為你收集整理的java什么是重构 何时使用重构_Java 之重构现有系统实战（一）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。