總覽 第1章 重構(gòu)，第一個(gè)案例

• 1.1 (P1)起點(diǎn)
• 1.2 (P7)重構(gòu)的第一步

第2章 重構(gòu)原則

• 2.1 (P53)何謂重構(gòu)
• 2.2 (P55)為何重構(gòu)
• 2.3 (P57)何時(shí)重構(gòu)
• 2.4 (P60)怎么對(duì)經(jīng)理說
  • 間接訪問
• 2.5 (P62)重構(gòu)的難題
• 2.6 (P66)重構(gòu)與設(shè)計(jì)
• 2.7 (P69)重構(gòu)與性能

第3章 代碼的壞味道

• 3.1 (P76)Duplicated Code（重復(fù)代碼）
• 3.2 (P76)Long Method（過長(zhǎng)函數(shù)）
• 3.3 (P78)Large Class（過大的類）
• 3.4 (P78)Long Parameter List（過長(zhǎng)參數(shù)列）
• 3.5 (P79)Divergent Change（發(fā)散式變化）
• 3.6 (P80)Shotgun Surgery（霰彈式修改）
• 3.7 (P80)Feature Envy（依戀情結(jié)）
• 3.8 (P81)Data Clumps（數(shù)據(jù)泥團(tuán)）
• 3.9 (P81)Primitive Obsession（基本類型偏執(zhí)）
• 3.10 (P82)Switch Statements（switch驚悚現(xiàn)身）
• 3.11 (P83)Parallel Inheritance Hierarchies（平行繼承體系）
• 3.12 (P83)Lazy Class（冗贅類）
• 3.13 (P83)Speculative Generality（夸夸其談未來性）
• 3.14 (P84)Temporary Field（令人迷惑的暫時(shí)字段）
• 3.15 (P84)Message Chains（過度耦合的消息鏈）
• 3.16 (P85)Middle Man（中間人）
• 3.17 (P85)Inappropriate Intimacy（狎昵關(guān)系）
• 3.18 (P85)Alternative Classes with Different Interfaces（異曲同工的類）
• 3.19 (P86)Incomplete Library Class（不完美的庫類）
• 3.20 (P86)Data Class（幼稚的數(shù)據(jù)類）
• 3.21 (P87)Refused Bequest（被拒絕的遺贈(zèng)）
• 3.22 Comments（過多的注釋）87

第4章 構(gòu)筑測(cè)試體系

• 4.1 自測(cè)試代碼的價(jià)值89
• 4.2 JUnit測(cè)試框架91
• 4.3 添加更多測(cè)試97

第12章 大型重構(gòu)359 第13章 重構(gòu)，復(fù)用與現(xiàn)實(shí)379

• 安全重構(gòu)（391）
• 重構(gòu)工具

第14章 重構(gòu)工具401

《重構(gòu)》的讀書筆記

學(xué)習(xí)基礎(chǔ)：

熟悉《設(shè)計(jì)模式》的基本概念，熟悉基本的Java語法，熟悉Eclipse和JUnit的使用，有相對(duì)較好的英語基礎(chǔ)。

學(xué)習(xí)過程：

• 先看第1章，手工輸入實(shí)例程序，了解重構(gòu)的方法和過程。重點(diǎn)是理解重構(gòu)的思路，最好的理解方式就是通過實(shí)踐的方式理解。
• 再看第2~4章，內(nèi)容為選擇性閱讀，沒興趣或者看不懂的都可以跳過，因?yàn)楹竺孢€可以回頭再讀。
• 接著第5~12章，最好按順序把代碼一個(gè)個(gè)輸入，再按照作者的步驟重構(gòu)操作一次，并結(jié)合自己以往工作中的實(shí)踐來理解。

學(xué)習(xí)目的：

使自己編寫的代碼更容易被人讀懂。

學(xué)習(xí)感悟：

• 代碼的重構(gòu)應(yīng)該是一步步完成的，每次重構(gòu)的部分不要超過自己的理解能力的5%。雖然這樣操作略顯繁瑣，但是可以減輕頭腦重構(gòu)過程中的記憶強(qiáng)度，減少代碼出錯(cuò)的機(jī)會(huì)。
• 代碼的重構(gòu)一定要配合JUnit（TDD，測(cè)試驅(qū)動(dòng)開發(fā)）完成，再加上Git（版本管理）和Eclipse（IDE的重構(gòu)工具）那就事半功倍了。

學(xué)習(xí)代碼：

Refactored-MartinFowler

總覽

• 第1章（必讀），從實(shí)例程序出發(fā)，了解重構(gòu)的方法和過程。
• 第2章，討論重構(gòu)的一般性原則、定義和進(jìn)行重構(gòu)的原因。
• 第3章，介紹如何判斷問題代碼，以及如何用重構(gòu)改善它們。
• 第4章，在代碼中構(gòu)建java的測(cè)試環(huán)境
• 第5~12章，具體面對(duì)的問題和重構(gòu)的方法。
• 第13章，Bill Opdyke在商業(yè)開發(fā)中應(yīng)用重構(gòu)
• 第14章，自動(dòng)化重構(gòu)工具（今天看來，已經(jīng)不是太大問題，Eclipse的Refactor已經(jīng)非常好用）
• 第15章，重構(gòu)的哲學(xué)思想

第1章 重構(gòu)，第一個(gè)案例

1.1 (P1)起點(diǎn)

因?yàn)榇a的結(jié)構(gòu)無法滿足添加新功能的需要，因此先進(jìn)行重構(gòu)，使代碼方便添加新功能，然后再添加新功能。

1.2 (P7)重構(gòu)的第一步

首先確認(rèn)自己擁有一套可靠的測(cè)試機(jī)制，因?yàn)橹貥?gòu)有可能引入問題，通過測(cè)試保證重構(gòu)沒有改變程序功能。

第2章 重構(gòu)原則

2.1 (P53)何謂重構(gòu)

重構(gòu)（名詞）：對(duì)軟件內(nèi)部結(jié)構(gòu)的一種調(diào)整，目的是在不改變軟件可觀察行為的前提下，提高理解性和降低修改成本。
重構(gòu)（動(dòng)詞）：使用一系列重構(gòu)手法，在不改變軟件可觀察行為的前提下，調(diào)整其結(jié)構(gòu)。
定義的擴(kuò)展：

• 重構(gòu)讓軟件更容易理解和修改
• 重構(gòu)不會(huì)改變軟件的可觀察行為，即使改變也只能是微小的影響，軟件功能一如既往。

重構(gòu)的目標(biāo)：只改變程序內(nèi)部結(jié)構(gòu)，不添加新的功能

不要一心二用：

• 添加新功能的時(shí)候，不重構(gòu)已有代碼。
• 重構(gòu)代碼時(shí)，不增加新功能。

2.2 (P55)為何重構(gòu)

• 重構(gòu)改進(jìn)軟件設(shè)計(jì)：
  • 程序的設(shè)計(jì)質(zhì)量在沒有持續(xù)重構(gòu)的情況下逐漸變差，功能的增加或者修改都可能使代碼越來越難以理解和維護(hù)，就越難保證最初的設(shè)計(jì)目標(biāo)
  • 消除重復(fù)的代碼一方面是程序運(yùn)行更快，一方面是方便未來的修改，例如：重構(gòu)減少代碼重復(fù)，避免功能的改變需要修改多處代碼。
• 重構(gòu)使軟件更容易理解：
  • 及時(shí)填補(bǔ)“想要它做什么”和“告訴它做什么”之間的縫隙。重構(gòu)的核心就是要“準(zhǔn)確說出我所要的”
  • 重新閱讀代碼的人有可能是自己，也可能是他人。
  • 通過重構(gòu)可以把自己不熟悉的代碼的用途梳理一遍，加深對(duì)代碼的理解
• 重構(gòu)幫助找出bug：
  • 這個(gè)是建立在代碼容易理解之上的
• 重構(gòu)提高編程速度：
  • 重構(gòu)達(dá)到良好的設(shè)計(jì)，而良好的設(shè)計(jì)更容易修改代碼、增加功能、問題調(diào)試。

2.3 (P57)何時(shí)重構(gòu)

重構(gòu)的三次法則：

• 第一次開發(fā)某個(gè)功能的時(shí)候以實(shí)現(xiàn)為目標(biāo)。
• 第二次開發(fā)相同功能的時(shí)候，克制自己的反感，繼續(xù)重復(fù)實(shí)現(xiàn)。
• 第三次開發(fā)相同功能的時(shí)候，應(yīng)該重構(gòu)。

重構(gòu)的時(shí)間點(diǎn)：

• 添加功能時(shí)重構(gòu)：
  • 一方面可以幫助理解需要修改的代碼
  • 一方面是使現(xiàn)在以及未來增加新功能更加容易。
• 修補(bǔ)錯(cuò)誤時(shí)重構(gòu)：
  • 出現(xiàn)bug的時(shí)候，難以找出問題所在的時(shí)候，很有可能是代碼不清晰導(dǎo)致查找bug的困難。
• 復(fù)審代碼時(shí)重構(gòu)：
  • 復(fù)審代碼有助于知識(shí)的傳播，有利于代碼被編寫者之外的人理解。
  • 重構(gòu)加深了對(duì)代碼的理解，有利于提升復(fù)審代碼的能力

復(fù)審團(tuán)隊(duì)：只要代碼作者和一個(gè)審查者者。較大的項(xiàng)目可以通過UML圖去展示代碼的邏輯。

程序難以修改的原因：

• 難以閱讀的程序
• 邏輯重復(fù)的程序
• 添加新特性需要修改已有代碼的程序
• 帶復(fù)雜邏輯判斷的程序

重構(gòu)的目標(biāo)：

• 代碼容易閱讀
• 所有邏輯都只有唯一地點(diǎn)指定
• 新的改動(dòng)不會(huì)危及現(xiàn)有行為
• 盡可能簡(jiǎn)單表達(dá)邏輯

2.4 (P60)怎么對(duì)經(jīng)理說

• 懂技術(shù)的經(jīng)理，很容易溝通；
• 追求質(zhì)量的經(jīng)理，介紹重構(gòu)對(duì)質(zhì)量的幫助；
• 追求進(jìn)度的經(jīng)理，則自己安靜地重構(gòu)。因?yàn)橹貥?gòu)可以最快的完成任務(wù)，就是對(duì)經(jīng)理最大的幫助。

間接訪問

很多時(shí)候重構(gòu)都為程序引入間接訪問：

• 把大型對(duì)象拆分成小對(duì)象
• 把大型函數(shù)拆分為小型函數(shù)。

間接訪問的價(jià)值：

• 允許邏輯共享：一個(gè)函數(shù)在不同地點(diǎn)被調(diào)用。子類共享超類的方法。
• 分開解釋意圖和實(shí)現(xiàn)：通過類名和函數(shù)名解釋自己的意圖
• 隔離變化：在不同地方使用同一個(gè)對(duì)象，需要修改一處邏輯，那么可以做出子類，并在需要的時(shí)候修改這個(gè)子類。
• 封裝條件邏輯：運(yùn)用多態(tài)。將條件邏輯轉(zhuǎn)化為消息模式。

減少間接層的條件:當(dāng)間接層只在一處使用，那么需要將其消除。

2.5 (P62)重構(gòu)的難題

數(shù)據(jù)庫重構(gòu)：

• 存在問題：
  • 程序與數(shù)據(jù)庫耦合在一起。
  • 數(shù)據(jù)遷移。
• 解決方案：
  • 在非關(guān)系型數(shù)據(jù)庫，可以在數(shù)據(jù)庫和對(duì)象模型中插入一個(gè)分離層，隔離兩者之間的變化

接口重構(gòu)

• 對(duì)于已經(jīng)發(fā)布的接口需要可能需要維護(hù)舊接口和新接口，用deprecated修飾舊接口。
• 不發(fā)布新接口，在舊接口中調(diào)用新接口。
• 假如新接口拋出編譯時(shí)異常，那么可以在舊接口中調(diào)用新接口并將編譯時(shí)異常轉(zhuǎn)化為運(yùn)行時(shí)異常。

不重構(gòu)的條件：

• 重構(gòu)之前，代碼在大部分情況下都能夠正常運(yùn)行，就可以重構(gòu)，否則應(yīng)該是重寫。
• 到了Deadline，應(yīng)該避免重構(gòu)。

2.6 (P66)重構(gòu)與設(shè)計(jì)

重構(gòu)與設(shè)計(jì)是彼此互補(bǔ)的：

• 設(shè)計(jì)應(yīng)該在編碼之前，但是設(shè)計(jì)總有缺陷，隨著對(duì)問題認(rèn)識(shí)的逐漸深入，通過重構(gòu)可以改善設(shè)計(jì)的質(zhì)量。
• 重構(gòu)減輕了設(shè)計(jì)的難度和壓力，在程序不斷修改的過程中逐步完善程序的設(shè)計(jì)。

2.7 (P69)重構(gòu)與性能

重構(gòu)是有可能導(dǎo)致程序運(yùn)行變慢的，但是不需要在設(shè)計(jì)和編碼時(shí)就考慮性能問題。例如：實(shí)時(shí)程序的編寫：

• 首先寫出可調(diào)的程序
• 然后調(diào)整它以達(dá)到性能的要求。
  • 經(jīng)過分析大部分程序的主要時(shí)間是消耗在小部分代碼上，所以不用對(duì)所有代碼進(jìn)行優(yōu)化。
  • 性能優(yōu)化放在開發(fā)的后期，利用分析工具找出消耗大量時(shí)間的代碼，然后集中優(yōu)化。

第3章 代碼的壞味道

3.1 (P76)Duplicated Code（重復(fù)代碼）

• 同個(gè)類兩個(gè)函數(shù)存在相同表達(dá)式：Extract Method（提煉函數(shù)）
• 互為兄弟類內(nèi)存在相同表達(dá)式：
  • Extract Method→PullUp Method（函數(shù)上移）
  • 如果代碼只是相似：先運(yùn)用Extract Method（提煉函數(shù)）分開再Form TemPlate Method（塑造模板函數(shù)）
• 兩個(gè)毫不相干的類存在重復(fù)代碼：Extract Class（提煉類）

3.2 (P76)Long Method（過長(zhǎng)函數(shù)）

原則：盡量利用函數(shù)名稱來解釋用途，而不是注釋。
關(guān)鍵：代碼主要用來描述“做什么”，而不是描述“怎么做”。例如：getAge()表達(dá)獲取年齡，而today-birthday就增加了理解的間接性，雖然看代碼的人也能明白含義，但是就需要多想一下，并且birthday有可能表達(dá)的不是某個(gè)人的出生日期呢，而是某個(gè)買回來的產(chǎn)品的呢？那可能表達(dá)的就是使用時(shí)長(zhǎng)了。
具體情況：

• 函數(shù)有大量參數(shù)和臨時(shí)變量：Extract Method（提煉函數(shù)）
• 用Replace Temp with Query（以查詢?nèi)〈R時(shí)變量）消除臨時(shí)變量
• 用Introduce Parameter Object（引入?yún)?shù)對(duì)象）或者Preserve Whole Object（保持對(duì)象完整）來將多長(zhǎng)的參數(shù)列表變得簡(jiǎn)潔一點(diǎn)。
• 如果按照上述步驟還存在太多變量和參數(shù)就需要用到Replace Method with Method Object（以函數(shù)對(duì)象取代函數(shù)）
• 條件表達(dá)式可以用Decompose Conditional（分解條件表達(dá)式）解決
• 可以將循環(huán)內(nèi)的代碼提煉為函數(shù)。

3.3 (P78)Large Class（過大的類）

有時(shí)候類并非在所有時(shí)刻都使用實(shí)例變量：使用Extract Method和Extract Subclass（提煉子類）

類中有太多代碼：

• Extract Class（提煉類）
• Extract Subclass（提煉子類）
• Extract Interface（提供接口）分解類的行為。存在GUI的時(shí)候，可以Duplicate Observed Data（復(fù)制“被監(jiān)視數(shù)據(jù)”），分離數(shù)據(jù)和行為到業(yè)務(wù)模型中去。

3.4 (P78)Long Parameter List（過長(zhǎng)參數(shù)列）

• 如果可以調(diào)用已有對(duì)象獲取的話可以使用Replace Parameter with Methods（以函數(shù)取代參數(shù)）
• 將來自同一對(duì)象的數(shù)據(jù)收集起來，以該對(duì)象替代：Preserve Whole Object（保持對(duì)象完整）
• 如果幾個(gè)參數(shù)總是同時(shí)出現(xiàn)，那么可以考慮Introduce Parameter Object（引入?yún)?shù)對(duì)象）

3.5 (P79)Divergent Change（發(fā)散式變化）

不同的變化影響著相同的類發(fā)生改變，即變化的認(rèn)知有分歧（Divergent）。通過Extract Class把不同的功能封裝到不同的類中，使每個(gè)類只因一種變化而需要修改

3.6 (P80)Shotgun Surgery（霰彈式修改）

相同的變化會(huì)涉及到多個(gè)類發(fā)生修改，類似霰彈槍射擊的效果。
可以通過Extract Method，Move Method，Inline Class把一種變化產(chǎn)生的多個(gè)修改移到同一個(gè)類中。

對(duì)比：

• Divergent Change（發(fā)散式變化）是一個(gè)類受到的多個(gè)變化影響；
• Shotgun Surgery（霰彈式修改）是一個(gè)變化引起多個(gè)類需要修改。

3.7 (P80)Feature Envy（依戀情結(jié)）

類中的某個(gè)函數(shù)對(duì)其他類的依賴度過高，則應(yīng)該通過Move Method（移動(dòng)函數(shù)）將它搬移到合適的類中。

3.8 (P81)Data Clumps（數(shù)據(jù)泥團(tuán)）

數(shù)據(jù)項(xiàng)總是成群結(jié)隊(duì)出現(xiàn)，通過Extract Class將它們提煉到一個(gè)獨(dú)立對(duì)象中，從而縮短參數(shù)列表，簡(jiǎn)化函數(shù)調(diào)用。

判斷數(shù)據(jù)項(xiàng)是否相關(guān)的方法：如果這些數(shù)據(jù)項(xiàng)不在一起時(shí)就失去了明確的含義，那么就可以把它們提煉成一個(gè)新的對(duì)象。

3.9 (P81)Primitive Obsession（基本類型偏執(zhí)）

• 有些字段可以用對(duì)象表示更準(zhǔn)確Replace Data Value with Object（以對(duì)象取代數(shù)據(jù)值）
• 對(duì)于不影響行為的類型碼可以Replace Type Code with Class（以類取代類型碼）
• 影響行為的類型碼可以Replace Type Code with Subclasses（以子類取代類型碼），類型碼在運(yùn)行時(shí)會(huì)變化就用Replace Type Code with State/Strategy（以State/Strategy取代類型碼）

3.10 (P82)Switch Statements（switch驚悚現(xiàn)身）

• 使用Replace Type Code with Subclasses（以子類取代類型碼）或者Replace Type Code with State/Strategy（以State/Strategy取代類型碼）
• 輕量級(jí)的解決方法：Replace Parameter with Explicit Methods（以明確函數(shù)取代參數(shù)）

3.11 (P83)Parallel Inheritance Hierarchies（平行繼承體系）

每當(dāng)為一個(gè)類增加子類必須也為另外一個(gè)類增加一個(gè)子類，那么就讓一個(gè)繼承體系的實(shí)例引用另一個(gè)繼承體系的實(shí)例。

3.12 (P83)Lazy Class（冗贅類）

沒用的類，使用Inline Class（內(nèi)聯(lián)類）或者Collapse Hierarchy（折疊繼承體系）來解決

3.13 (P83)Speculative Generality（夸夸其談未來性）

• 為未來設(shè)計(jì)的類，使用Inline Class（內(nèi)聯(lián)類）或者Collapse Hierarchy（折疊繼承體系）來解決
• 為未來設(shè)計(jì)的函數(shù)參數(shù)，使用Remove Parameter（移除參數(shù)）
• 函數(shù)名稱啰嗦，使用Rename Method（函數(shù)改名）

3.14 (P84)Temporary Field（令人迷惑的暫時(shí)字段）

對(duì)象中某個(gè)字段僅為特定情況而設(shè)。使用Extract Class（提煉類）將這個(gè)字段提取出來

3.15 (P84)Message Chains（過度耦合的消息鏈）

消息鏈：用戶通過一個(gè)對(duì)象獲取另一個(gè)對(duì)象，再通過獲取的對(duì)象請(qǐng)求另一個(gè)對(duì)象，如此操作就是消息鏈。采取這種方式意味著客戶代碼將與查找過程中的導(dǎo)航結(jié)構(gòu)緊密耦合，可以使用Hide Delegate（隱藏“委托關(guān)系”）進(jìn)行重構(gòu)。但是謹(jǐn)慎處理！

3.16 (P85)Middle Man（中間人）

過度委托形成中間人:Remove Middle Man（移除中間人）

如果中間人還有其他行為,Replace Delegation with Inherited（以繼承取代委托）

3.17 (P85)Inappropriate Intimacy（狎昵關(guān)系）

• 兩個(gè)類相互依賴過多，花費(fèi)大量時(shí)間去獲取對(duì)方的private成員內(nèi)容，使用Move Field（移動(dòng)字段）和Move Method（移動(dòng)方法）減少耦合性，或用Change Bidirectional Association to Unidirectional（將雙向關(guān)聯(lián)改為單向關(guān)聯(lián)）
• 如果兩個(gè)類無法移動(dòng)相同數(shù)據(jù)和函數(shù)，可以使用Extract Class（提煉類）,讓他們使用新類進(jìn)行交互。

3.18 (P85)Alternative Classes with Different Interfaces（異曲同工的類）

兩個(gè)函數(shù)做了相同的事情卻有不同的函數(shù)名稱

3.19 (P86)Incomplete Library Class（不完美的庫類）

庫函數(shù)功能不足，需要增加一些自定義的功能：

• 需要加入少量操作，使用Introduce Foreign Method（引入外加函數(shù)）
• 需要加入大量操作，使用Introduce Local Extension（引入本地?cái)U(kuò)展）

3.20 (P86)Data Class（幼稚的數(shù)據(jù)類）

幼稚的數(shù)據(jù)類：只有數(shù)據(jù)沒有行為的類，其他類需要對(duì)該類的數(shù)據(jù)進(jìn)行取值設(shè)值操作

• 使用Encapsulate Field（封裝字段）和Encapsulate Collection（封裝集合）對(duì)字段進(jìn)行合理地封裝
• 對(duì)于不該被其他類修改的字段:Remove Setting Method（移除設(shè)值函數(shù)）

3.21 (P87)Refused Bequest（被拒絕的遺贈(zèng)）

如果子類不愿意接受超類的所有定義，應(yīng)該使用Replace inherited with Delegation（以委托取代繼承）來處理子類

3.22 Comments（過多的注釋）87

使用Extract Method（提煉方法）來解決注釋過多問題，注釋更多應(yīng)該說明的是“怎么做”，而不是“做什么”，例如：對(duì)一個(gè)排序函數(shù)說明其采用二分法排序，而不是說明它是個(gè)排序函數(shù)，因?yàn)檫@個(gè)說明在函數(shù)名稱中已經(jīng)具備。

第4章 構(gòu)筑測(cè)試體系

4.1 自測(cè)試代碼的價(jià)值89

• 確保所有測(cè)試都完全自動(dòng)化，讓它們檢查自己的測(cè)試結(jié)果；
• 一套測(cè)試就是一個(gè)強(qiáng)大的bug探測(cè)器，能夠大大縮減查找bug所需要花費(fèi)的時(shí)間。
  • 因?yàn)榇a剛剛寫完，測(cè)試出現(xiàn)問題后，心里很清楚自己修改或者添加了哪些東西，可能會(huì)在哪里出現(xiàn)了問題。

    4.2 JUnit測(cè)試框架91

• 頻繁地運(yùn)行測(cè)試；
• 每次編譯前都進(jìn)行一次測(cè)試；
• 每天至少執(zhí)行一次所有的測(cè)試。

  4.3 添加更多測(cè)試97

• 編寫一個(gè)測(cè)試并運(yùn)行起來，好過將所有的測(cè)試編好了一起運(yùn)行。
• 測(cè)試特別需要注意可能出錯(cuò)的邊界條件；
• 對(duì)于可能出錯(cuò)的地方，還需要檢查是否拋出了預(yù)期的異常；
• 測(cè)試不能解決所有bug，但是可以大大減少bug的數(shù)量。

第12章 大型重構(gòu)359

大型重構(gòu)是程序開發(fā)必將遇到的，只是不知道在什么時(shí)間，用什么樣的方式經(jīng)歷。例如：隨著時(shí)間的推移，河道必定會(huì)被水草和垃圾所堵塞，你可以固定時(shí)間清淤，也可以放任自流直到崩潰。崩潰后依然會(huì)面臨總結(jié)經(jīng)驗(yàn)教訓(xùn)，再次重構(gòu)系統(tǒng)。
大型重構(gòu)很難給出具體的操作案例，因?yàn)槊總€(gè)大型案例相對(duì)于自身來說都是惟一的，是無法復(fù)制和重現(xiàn)的?？梢詮?fù)制與重現(xiàn)的都是這些大型重構(gòu)中蘊(yùn)含的具體的細(xì)節(jié)，因此這章主要講的是思想和理念上的內(nèi)容。
四個(gè)大型重構(gòu)：

• Tease Apart Inheritance（362）用于處理混亂的繼承體系
  • 某個(gè)繼承體系同時(shí)承擔(dān)兩項(xiàng)責(zé)任
  • 建立兩個(gè)繼承體系，其中一個(gè)通過委托調(diào)用另一個(gè)
• Convert Procedural Design to Objects（368）如何重構(gòu)過時(shí)的編碼技術(shù)遺留下來的程序
  • 傳統(tǒng)過程化風(fēng)格的代碼
  • 將數(shù)據(jù)記錄變成對(duì)象，將大塊的行為分成小塊，再將它們移入到相關(guān)對(duì)象中
• Separate Domain from Presentation（370）將業(yè)務(wù)邏輯與用戶界面分隔開來
  • 用戶界面類中包含了業(yè)務(wù)邏輯
  • 將業(yè)務(wù)邏輯剝離到業(yè)務(wù)類中，參考：MVC模式
• Extract Hierarchy（375）將復(fù)雜的類轉(zhuǎn)化為一群簡(jiǎn)單的子類，從而簡(jiǎn)化系統(tǒng)。
  • 某個(gè)類做了太多工作
  • 某個(gè)類的部分工作是由大量的條件表達(dá)式完成的
  • 建立繼承體系，使用子類表示每一種特殊情況

第13章 重構(gòu)，復(fù)用與現(xiàn)實(shí)379

作為一個(gè)博士寫的內(nèi)容，仍然具有學(xué)術(shù)性較強(qiáng)的風(fēng)格，可以當(dāng)作歷史資料了解一下重構(gòu)的發(fā)展過程，也可以對(duì)重構(gòu)的思想有更多理論上的認(rèn)識(shí)。

安全重構(gòu)（391）

安全重構(gòu)的四條籬笆：

• 相信你自己的編碼能力；
• 相信你的編譯器能捕捉你遺漏的錯(cuò)誤；
• 相信你的測(cè)試套件能捕捉你和編譯器都遺漏的錯(cuò)誤；
• 相信代碼復(fù)審能捕捉你、編譯器和測(cè)試套件都遺漏的錯(cuò)誤。注：沒有100%安全的重構(gòu)，但是可以通過以上的條件滿足你對(duì)安全性的最低要求。

重構(gòu)工具

• Eclipse（或其他IDE）自帶的重構(gòu)工具：Refactor；
• Java（或其他編譯器）自帶的分析工具：lint；
• JUnit等自動(dòng)化的測(cè)試工具。

第14章 重構(gòu)工具401

相對(duì)于10多年前寫的內(nèi)容，現(xiàn)在許多IDE都已經(jīng)提供了對(duì)大部分重構(gòu)功能的支持。但是了解重構(gòu)的基本理念，對(duì)于正確地使用重構(gòu)工具會(huì)有很大的幫助。因?yàn)槌晒Φ闹貥?gòu)不依賴于工具，而決定于人，當(dāng)人做出了正確的決定，合理地使用重構(gòu)工具輔助自己，才能保證重構(gòu)的完成。

轉(zhuǎn)載于:https://www.cnblogs.com/zhuyx/p/10278392.html

總結(jié)

以上是生活随笔為你收集整理的《重构》的读书笔记的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。