本文關(guān)鍵詞：重構(gòu)與模式，由筆耕文化傳播整理發(fā)布。

    

一、改善代碼的三部曲

   《設(shè)計模式》-> 《重構(gòu)》-> 《重構(gòu)與模式》。也就是設(shè)計->重構(gòu)->重構(gòu)出新設(shè)計。

   《設(shè)計模式》主要詳細說明20幾種模式，為我們帶來了常見設(shè)計問題的經(jīng)典解決方案，從而改變了整個面向?qū)ο箝_發(fā)的面貌。為設(shè)計而著。

   《重構(gòu)》改善既有代碼的設(shè)計，總結(jié)了我們會用到的各種重構(gòu)手法，為我們帶來了一種改進代碼的高效過程，從而徹底改變了面向?qū)ο笤O(shè)計的方式。側(cè)重去除壞代碼的味道。

    《重構(gòu)與模式》是設(shè)計模式相關(guān)的重構(gòu)。模式不是設(shè)計出來的，是重構(gòu)出來的。好的設(shè)計也不是設(shè)計出來的，是重構(gòu)出來的。不要怕改變，只要改變得法，變就不再是災(zāi)難，而是進步的良機。側(cè)重設(shè)計模式+重構(gòu)手段。

      在閱讀重構(gòu)與模式之前，最好熟讀前面兩本：《設(shè)計模式》和《重構(gòu)》。

      設(shè)計模式代表了傳統(tǒng)的軟件開發(fā)思想：好的設(shè)計會產(chǎn)生好的軟件，因此在實際開發(fā)之前，值得花時間去做一個全面而細致的設(shè)計。重構(gòu)代表了敏捷軟件開發(fā)的浪潮：軟件并不是在一開始就可以設(shè)計得完美無缺的，因此可以先進行實際開發(fā)，然后通過對代碼不斷的進行小幅度的修改來改善其設(shè)計。二者從不同角度闡述了設(shè)計的重要性。

      有些人在編寫任何代碼之前，都要很早地為模式做計劃，而有些人在編寫了大量代碼之后才開始添加模式。
第二種使用模式的方式就是重構(gòu)，因為是要在不增加系統(tǒng)特性或者不改變其外部行為的情況下改變系統(tǒng)的設(shè)計。
有些人在程序中加入模式，只是因為覺得模式能夠使程序更容易修改；更多人這樣做只是為了簡化目前的設(shè)計。
如果代碼已經(jīng)編寫，這兩種情形都是重構(gòu)，因為前者是通過重構(gòu)使修改更容易，而后者則是通過重構(gòu)在修改后進行整理。
雖然模式是在程序中能夠看到的東西，但是模式也是一種程序轉(zhuǎn)換。
     重構(gòu)是實現(xiàn)設(shè)計模式的一種手段，設(shè)計模式往往也是重構(gòu)的目的。

二、重構(gòu)與模式的緣由

     應(yīng)該通過重構(gòu)實現(xiàn)模式、趨向模式和去除模式(refactoring to, towards, and away from pattern)，而不是在預(yù)先設(shè)計中使用模式，也不再過早的在代碼中加入模式。這技能避免過度設(shè)計，又不至于設(shè)計不足。

但是后來卻沒怎么動，也就是導(dǎo)致了廢設(shè)計和功能.

 2.設(shè)計不足

    產(chǎn)生設(shè)計不足的原因：
    1）程序員沒有時間，沒有抽出時間，或者時間不允許進行重構(gòu)

    2）程序員在何為好的軟件設(shè)計方面知識不足
    3）程序員被要求在既有系統(tǒng)中快速的添加新功能
    4）程序員被迫同時進行太多項目
    長期的設(shè)計不足，會使軟件開發(fā)節(jié)奏變成“快，慢，更慢”，可能的后果是：
    1.0版本很快就交付了，但是代碼質(zhì)量很差
    2.0版本也交付了，但質(zhì)量低劣的代碼使我們慢下來
    在企圖交付未來版本時，隨著劣質(zhì)代碼的倍增，開發(fā)速度也越來越慢，最后人們對系統(tǒng)、程序員乃至使大家陷入這種境地的整個過程都失去了信心
    到了4.0版本時或者之后，我們意識到這樣肯定不行，開始考慮推倒重來

 3.測試驅(qū)動開發(fā)和持續(xù)重構(gòu)，

  測試驅(qū)動開發(fā)和持續(xù)重構(gòu)提供了一種精益、迭代和訓(xùn)練有素的編程風(fēng)格，能夠最大程度的有張有弛，提高生產(chǎn)率�！把杆俣謴娜莶黄取�

  使用測試驅(qū)動開發(fā)和持續(xù)重構(gòu)的益處：

   1）保持較低的缺陷數(shù)量

   2）大膽的進行重構(gòu)

   3）得到更加簡單、更加優(yōu)秀的代碼

   4）編程時沒有壓力

  模式和重構(gòu)之間存在著天然聯(lián)系，模式是你想達到的目的地，而重構(gòu)則是從其他地方抵達這個目的地的條條道路。

 4.演進式設(shè)計

演進式設(shè)計即趨向性設(shè)計，主要是避免過度設(shè)計。

通過重構(gòu)產(chǎn)生設(shè)計結(jié)構(gòu)，也就是通過重構(gòu)實現(xiàn)模式或者重構(gòu)趨向模式。為設(shè)計而設(shè)計的思路并不適合大項目，循序漸進從重構(gòu)到設(shè)計模式才是設(shè)計模式的王道。

敏捷開發(fā)中經(jīng)常采用的演進式架構(gòu)設(shè)計：

很多程序員可能都遇見過這種事：某塊代碼亟待修改，卻沒有人愿意接手。為什么會這樣？這段代碼正巧是兩個組件間的接口，修改工作太過困難。而在演進式設(shè)計中，我們常常會做這種修改。代碼應(yīng)當(dāng)是"活的"并且是"可生長"的，決不能無視強烈的變化需求 而保持一成不變。正因為如此，演進式設(shè)計可以提高設(shè)計質(zhì)量，進而提高整個系統(tǒng)的質(zhì)量。

第6章創(chuàng)建

6.1 用Creating Method替換構(gòu)造函數(shù)

  當(dāng)類中有多個構(gòu)造函數(shù)，因此很難決定在開發(fā)期間用哪一個時，可以用能夠說明意圖的返回對象實例的Creation Method替換構(gòu)造函數(shù)

動機：

  Creation Method——類中的一個靜態(tài)或者非靜態(tài)的負責(zé)實例化類的新實例方法。因Creating Method命名沒有限制，所以可以取最能表達所創(chuàng)建對象的名字。

  類中有太多構(gòu)造函數(shù)→提煉類或者提煉子類 或者 用Creation Method替換構(gòu)造函數(shù)來澄清構(gòu)造函數(shù)的意圖

優(yōu)缺點：

  + 比構(gòu)造函數(shù)能夠更好的表達所創(chuàng)建的實例種類

  + 避免了構(gòu)造函數(shù)的局限，比如兩個構(gòu)造函數(shù)的參數(shù)數(shù)目和類型不能相同

  + 更容易發(fā)現(xiàn)無用的創(chuàng)建代碼

  - 創(chuàng)建方式是非標(biāo)準(zhǔn)的，有的用new實例化，而有的用Creation Method實例化

變體：

  不需要為每個對象的配置都設(shè)立一個Creation Method，非必要情況下可以添加參數(shù)來減少Creation Method的數(shù)量

  當(dāng)Creation Method過多的分散了類的主要職責(zé)是，應(yīng)該考慮將相關(guān)的Creation Method重構(gòu)為一個Factory

6.2 將創(chuàng)建知識搬移到Factory

  當(dāng)用來實例化一個類的數(shù)據(jù)和代碼在多個類中到處都是時，可以講有關(guān)創(chuàng)建的知識搬移到一個Factory中

動機：

  創(chuàng)建蔓延——將創(chuàng)建的職責(zé)放在了不應(yīng)該承擔(dān)對象創(chuàng)建任務(wù)的類中，，是解決方案蔓延中的一種，一般是之前的設(shè)計問題導(dǎo)致。

  使用一個Factory類封裝創(chuàng)建邏輯和客戶代碼的實例化選項，客戶可以告訴Factory實例如何實例化一個對象，然后用同一個Factory實例在運行時執(zhí)行實例化。

  Factory不需要用具體類專門實現(xiàn)，可以使用一個接口定義Factory，然后讓現(xiàn)有的類實現(xiàn)這個接口。

  如果Factory中創(chuàng)建邏輯過于復(fù)雜，應(yīng)將其重構(gòu)為Abstract Factory，客戶代碼可以配置系統(tǒng)使用某個ConcreteFactory（AbstractFactory的一個具體實現(xiàn)）或者默認的ConcreteFactory。

  只有確實改進了代碼設(shè)計，或者無法直接進行實例化時才有足夠的理由進行Factory重構(gòu)

優(yōu)缺點：

  + 合并創(chuàng)建邏輯和實例化選項

  + 將客戶代碼與創(chuàng)建邏輯解耦

  - 如果可以直接實例化，會使設(shè)計復(fù)雜化

6.3 用Factory封裝類

  當(dāng)直接實例化處在同一包結(jié)構(gòu)中、實現(xiàn)統(tǒng)一接口的多個類�？梢园杨惖臉�(gòu)造函數(shù)聲明為非公共的，并通過Factory來創(chuàng)建它們的實例

動機：

  可以通過Factory將一組客戶并不需關(guān)心的子類屏蔽到包內(nèi)部。

  如果類共享一個通用的公共接口、共享相同的超類、并且處在同一包結(jié)構(gòu)中，該重構(gòu)可能有用。

優(yōu)缺點：

  + 通過意圖導(dǎo)向的Creation Method簡化了不同種類實例的創(chuàng)建

  + 通過隱藏不需要公開的類減少了包的“概念重量”

  + 幫助嚴(yán)格執(zhí)行“面向接口編程，而不是面向?qū)崿F(xiàn)”這一格言

  - 當(dāng)需要創(chuàng)建新種類的實例時，必須更新Creation Method

  - 當(dāng)客戶只能獲得Factory的二進制代碼而無法獲得源碼時，對Factory的定制將受到限制

6.4 用Factory Method引入多態(tài)創(chuàng)建

  當(dāng)一個層次中的類都相似的實現(xiàn)一個方法，只是對象創(chuàng)建的步驟不同時，可以創(chuàng)建調(diào)用Factory Method來處理實例化方法的唯一超類版本

動機：

  Factory Method是OOP中最常見的模式，因其提供了多臺創(chuàng)建對象的方法

  使用Factory Method后的代碼往往比在類中賦值方法來創(chuàng)建自定義對象要簡單

  使用Factory Method的主要情況：

    當(dāng)兄弟子類實現(xiàn)了除對象創(chuàng)建步驟外都很相似的方法時

    當(dāng)超類和子類實現(xiàn)了除對象創(chuàng)建步驟外都很相似的方法時

優(yōu)缺點：

  + 減少因創(chuàng)建自定義對象而產(chǎn)生的重復(fù)代碼

  + 有效的表達了對象創(chuàng)建發(fā)生的位置，以及如何重寫對象的創(chuàng)建

  + 強制Factory Method使用的類必須實現(xiàn)統(tǒng)一的類型

  - 可能會向Factory Method的一些實現(xiàn)者傳遞不必要的參數(shù)

6.5 用Builder封裝Composite

  當(dāng)構(gòu)造Composite是重復(fù)的、復(fù)雜的且容易出錯的工作時，通過使用Builder處理構(gòu)造細節(jié)來簡化構(gòu)造過程。

動機：

  構(gòu)造Composite是重復(fù)的、復(fù)雜的、容易出錯的工作，通過使用Builder處理構(gòu)造細節(jié)來簡化構(gòu)造過程

  Builder模式很擅長處理繁重的、復(fù)雜的構(gòu)造步驟。

  Builder模式的意圖：將一個復(fù)雜對象的構(gòu)建與它的表示分離，使得同樣的構(gòu)建過程可以創(chuàng)建不同的表示。

優(yōu)缺點：

  + 簡化了構(gòu)造Composite的客戶代碼

  + 減少了創(chuàng)建Composite的重復(fù)和易出錯的本性

  + 在客戶代碼和Composite之間實現(xiàn)了松耦合

  + 允許對已封裝的Composite或復(fù)雜對象創(chuàng)建不同的表示

  - 接口可能不會很清楚的表達其意圖

6.6 內(nèi)聯(lián)Singleton

  當(dāng)代碼需要訪問一個對象，但是不需要對象的全局入口時，可以把Singleton的功能搬移到一個保存并提供對象訪問入口的類中。刪除Singleton。

動機：

  Singleton意圖：確保一個類僅有一個實例，并提供一個訪問它的全局訪問點

  保持暴露對象和保護對象之間的平衡對維護系統(tǒng)的靈活性是至關(guān)重要的

  任何全局?jǐn)?shù)據(jù)在被證明是無害之前都是有害的

  如果遇到本不該實現(xiàn)為Singleton的Singleton，不要猶豫，內(nèi)聯(lián)它！

優(yōu)缺點：

  + 使對象的協(xié)作變得更明顯和明確

  + 保護了單一的實例，且不需要特殊的代碼

  - 當(dāng)在許多層次間傳遞對象實例比較困難的時候，會使設(shè)計變得復(fù)雜

第7章 簡化

  我們所編寫的絕大部分代碼都不會從一開始就很簡單。

  算法經(jīng)常會因為支持多種變化而變得復(fù)雜。

  控制狀態(tài)轉(zhuǎn)換的轉(zhuǎn)換的邏輯往往會變得越來越復(fù)雜。

7.1 組合方法

  當(dāng)你無法迅速的理解一個方法的邏輯時，把方法的邏輯轉(zhuǎn)換成幾個同一層面上的、能夠說明意圖的步驟。

動機：

  Composed Method由對其他方法的調(diào)用組成，好的Composed Method的代碼都在細節(jié)的同一層面上。

  Composed Method一般不會引入性能問題

優(yōu)缺點：

  + 清晰的描述了一個方法所實現(xiàn)的功能以及如何實現(xiàn)

  + 把方法分解成命名良好的、處在細節(jié)的同一層面上的行為模塊，以此來簡化方法

  - 可能會產(chǎn)生過多的小方法

  - 可能會使調(diào)試變得困難，因為程序的邏輯分散在許多小方法中

Composed Method指導(dǎo)原則：

  Composed Method都很小。一般在5行左右，很少超過10行

  刪除重復(fù)代碼和死代碼。除去明顯的和微妙的代碼重復(fù)，除去沒有被使用的代碼，以減少方法的代碼量

  表達意圖。清楚的命名程序中的變量、方法和參數(shù)，使它們明確表達意圖。

  簡化。轉(zhuǎn)換代碼，使它盡可能簡單。

  使用細節(jié)的統(tǒng)一層面。當(dāng)把一個方法分解成一組行為時，要保證這些行為在細節(jié)的相似層面上。

7.2 用Strategy替換條件邏輯

  當(dāng)方法中條件邏輯控制著應(yīng)該執(zhí)行計算的哪個變體時，為每個變體創(chuàng)建一個Strategy并使方法把計算委托到Strategy實例。

 

動機：

  ——為算法的各個變體生成一系列的類，并用Strategy的一個實例裝配主類，主類在運行時委托到該Strategy實例

  復(fù)雜的條件邏輯是最常導(dǎo)致復(fù)雜度上升的地點之一

優(yōu)缺點：

  + 通過減少或去除條件邏輯使算法變得清晰易懂

  + 通過把算法的變體搬移到類層次中簡化了類

  + 允許在運行時用一種算法替換另一種算法

  - 當(dāng)應(yīng)用基于繼承的解決方案或“簡化條件表達式”中的重構(gòu)更簡單時，會增加設(shè)計的復(fù)雜度

  - 增加了算法如何獲取或接收上下文類數(shù)據(jù)的復(fù)雜度

7.3 將裝飾功能搬移到Decorator

  當(dāng)代碼向類和核心職責(zé)提供裝飾功能時，可以考慮將裝飾代碼搬移到Decorator

  無論多么喜歡一個模式，不要在不必要的時候使用它

優(yōu)缺點：

  + 把裝飾功能從類中移除，從而簡化類

  + 有效的把類的核心職責(zé)和裝飾功能區(qū)分開來

  + 可以去除幾個相關(guān)類中重復(fù)的裝飾邏輯

  - 改變了被裝飾對象的類型

  - 會使代碼變得更難理解和調(diào)試

  - 當(dāng)Decorator組合產(chǎn)生負面影響的時候，會增加設(shè)計的復(fù)雜度

7.4 用State替換狀態(tài)改變條件語句

  當(dāng)控制一個對象狀態(tài)轉(zhuǎn)換的條件表達式過于復(fù)雜時，可以考慮用處理特殊狀態(tài)轉(zhuǎn)換的State類替換條件語句

優(yōu)缺點：

  + 減少或去除狀態(tài)改變條件邏輯

  + 簡化了復(fù)雜的狀態(tài)改變邏輯

  + 提供了觀察狀態(tài)改變邏輯的很好的鳥瞰圖

  - 當(dāng)狀態(tài)轉(zhuǎn)換邏輯已經(jīng)易于理解的時候，會增加設(shè)計的復(fù)雜度

7.5 用Composite替換隱含樹

  當(dāng)用原生表示法隱含的形成了樹結(jié)構(gòu)時，可以考慮用Composite替換這個原生表示法

 

優(yōu)缺點：

  + 封裝重復(fù)的指令，如格式化、添加或刪除結(jié)點

  + 提供了處理相似邏輯增長的一般性方法

  + 簡化了客戶代碼的構(gòu)造職責(zé)

  - 當(dāng)構(gòu)造隱式樹更簡單的時候，會增加設(shè)計的復(fù)雜度

7.6 用Command替換條件調(diào)度程序

  當(dāng)條件邏輯用來調(diào)度請求和執(zhí)行操作時，為每個動作創(chuàng)建一個Command。把這些Command存儲在一個集合中，并用獲取及執(zhí)行Command的代碼替換條件邏輯。

 

  為每個動作創(chuàng)建一個Command，把這些Command存儲在一個集合中，并用獲取及執(zhí)行Command的代碼替換條件邏輯

優(yōu)缺點：

  + 提供了用統(tǒng)一方法執(zhí)行不同行為的簡單機制

  + 允許在運行時改變所處理的請求，以及如何處理請求

  + 僅僅需要很少的代碼實現(xiàn)

  - 當(dāng)條件調(diào)度程序已經(jīng)足夠的時候，會增加設(shè)計的復(fù)雜度

第8章 泛化

  泛化是把特殊代碼轉(zhuǎn)換成通用目的代碼的過程。泛化代碼的產(chǎn)生往往的重構(gòu)的結(jié)果。

8.1 形成Template Method

  當(dāng)子類中的兩個方法以相同的順序執(zhí)行相似的步驟，但是步驟并不完全相同。通過把這些步驟提取成具有相同簽名的方法來泛化這兩個方法，然后上移這些泛化方法，形成Template Method。

 

優(yōu)缺點：

  + 通過把不變行為搬移到超類，去除子類中的重復(fù)代碼

  + 簡化并有效的表達了一個通用算法的步驟

  + 允許子類很容易的定制一個算法

  - 當(dāng)為了生成算法，子類必須實現(xiàn)很多方法的時候，會增加設(shè)計的復(fù)雜度

8.2 提取Composite

  當(dāng)一個類層次結(jié)構(gòu)中的多個子類實現(xiàn)了同一個Composite時，可以提取一個實現(xiàn)該Composite的超類

 

優(yōu)缺點：

  + 去除重復(fù)的類存儲邏輯和類處理邏輯

  + 能夠有效的表達類處理邏輯的可繼承性

8.3 用Composite替換一/多之分

  當(dāng)類使用不同的代碼處理單一對象與多個對象時，用Composite能夠產(chǎn)生既可以處理單一對象又可以處理多個對象的代碼

 

優(yōu)缺點：

  + 去除與處理一個或多個對象相關(guān)聯(lián)的重復(fù)代碼

  + 提供處理一個或多個對象的統(tǒng)一方法

  + 支持處理多個對象的更豐富的方法

  - 可能會在Composite的構(gòu)造過程中要求類型安全的運行時檢查

8.4 用Observer替換硬編碼的通知

  當(dāng)子類通過硬編碼來通知另一個類的實例時可以去除這些子類，并使其超類能夠通知一個或多個實現(xiàn)了Observer接口的類

 

優(yōu)缺點：

  + 使主題及其觀察者訪問松散耦合

  + 支持一個或多個觀察者

  - 當(dāng)硬編碼的通知已經(jīng)足夠的時候，會增加設(shè)計的復(fù)雜度

  - 當(dāng)出現(xiàn)串聯(lián)通知的時候，會增加代碼的復(fù)雜度

  - 當(dāng)觀察者沒有從它們的主題中被刪除的時候，可能會造成資源泄漏

8.5 通過Adapter統(tǒng)一接口

  當(dāng)客戶代碼與兩個類交互，其中的一個類具有首選接口，可以用一個Adapter統(tǒng)一接口

 

動機：

  當(dāng)下面條件都為真時，重構(gòu)Adapter就是有用的：

    兩個類所做的事情相同或相似，但是具有不同的接口

    如果類共享同一個接口，客戶代碼會更簡單、更直接、更緊湊

    無法輕易改變其中一個類的接口，因為它是第三方庫中的一部分，或者它是一個已經(jīng)被其他客戶代碼廣泛使用的框架的一部分，或者無法獲得源碼

優(yōu)缺點：

  + 使客戶代碼可以通過相同的接口與不同的類交互，從而去除或減少重復(fù)代碼

  + 使客戶代碼可以通過公共的接口與多個對象交互，從而簡化了客戶代碼

  + 統(tǒng)一了客戶代碼與不同類的交互方式

  - 當(dāng)類的接口可以改變的時候，會增加設(shè)計的復(fù)雜度

8.6 提取Adapter

  當(dāng)一個類適配了多個版本的組件、類庫、API或其他實體時，可以為組件、類庫、API或其他實體的每個版本提取一個Adapter

 

  Adapter用來適配對象，F(xiàn)acade用來適配整個系統(tǒng)，F(xiàn)acade通常用來與遺留系統(tǒng)進行交互

優(yōu)缺點：

  + 隔離了不同版本的組件、類庫或API之間的不同之處

  + 使類只負責(zé)適配代碼的一個版本

  + 避免頻繁的修改代碼

  - 如果某個重要行為在Adapter中不可用的話，那么客戶代碼將無法執(zhí)行這一重要行為

8.7 用Interpreter替換隱式語言

  當(dāng)類中的許多方法組合成了一種隱式語言的元素，可以為隱式語言的元素定義類，這樣就可以通過類實例組合，形成易于理解的表達式

 

優(yōu)缺點：

  + 比隱式語言更好的支持語言元素的組合

  + 不需要解析新的代碼來支持語言元素的新組合

  + 允許行為的運行時配置

  - 會產(chǎn)生定義語言和修改客戶代碼的開銷

  - 如果語言很復(fù)雜，則需要很多的編程工作

  - 如果語言本身就很簡單，則會增加設(shè)計的復(fù)雜度

第9章 保護

9.1 用類替換類型代碼

  字段的類型無法保護它免受不正確的復(fù)制和非法的等同性比較，可以把字段的類型聲明為類，從而限制復(fù)制和等同性比較

 

優(yōu)缺點：

  + 更好的避免非法賦值和比較

  - 比使用不安全類型要求更多的代碼

9.2 用Singleton限制實例化

  代碼創(chuàng)建了一個對象的多個實例，并導(dǎo)致內(nèi)存使用過多和系統(tǒng)性能下降時，可以用Singleton替換多個實例

 

  不要做不成熟的代碼優(yōu)化，經(jīng)過不成熟優(yōu)化的代碼比未優(yōu)化的代碼更難于重構(gòu)。在代碼優(yōu)化之前，你會發(fā)現(xiàn)更多可以改進的地方

優(yōu)缺點：

  + 改進性能

  - 在任何地方都可以很容易的訪問。在很多情況下，這可能是設(shè)計的缺點

  - 當(dāng)對象含有不能共享的狀態(tài)時，本重構(gòu)無效

9.3 引入Null Object

  當(dāng)代碼中到處都是處理null字段或變量的重復(fù)邏輯時，將null邏輯替換為一個Null Object，一個提供正確null行為的對象

 

優(yōu)缺點：

  + 不需要重復(fù)的null邏輯就可以避免null錯誤

  + 通過最小化null測試簡化了代碼

  - 當(dāng)系統(tǒng)不太需要null測試的時候，會增加設(shè)計的復(fù)雜度

  - 如果程序員不知道Null Object的存在，就會產(chǎn)生多余的null測試

  - 使維護變得復(fù)雜，擁有超類的Null Object必須重寫所有新繼承到的公共方法

第10章 聚集操作

10.1 將聚集操作搬移到Collecting Parameter

  有一個很大的方法將信息聚集到一個局部變量中時，可以把結(jié)果聚集到一個Collecting Parameter中，并將它傳入被提煉出的方法中

 

優(yōu)缺點：

  + 幫助我們把很大的方法轉(zhuǎn)換成更小的，更簡單的多個方法

  - 使結(jié)果代碼運行得更快

10.2 將聚集操作搬移到Visitor

  有一個方法從不同的類中聚集信息，可以把聚集工作搬移到一個能夠訪問每個類以便采集信息的Visitor中。

 

優(yōu)缺點：

  + 調(diào)節(jié)多個算法，使其適用于不同的對象結(jié)構(gòu)

  + 訪問相同或不同繼承結(jié)構(gòu)中的類

  + 調(diào)用不同類上的類型特定方法，無需類型轉(zhuǎn)換

  - 當(dāng)可以使用通用接口把互不相同的類變成相似類的時候，會增加代碼的復(fù)雜度

  - 新的可訪問類需要新的接收方法，每個Visitor中需要新的訪問方法

  - 可能會破壞訪問類的封裝性

第11章 使用重構(gòu)

11.1 鏈構(gòu)造函數(shù)

  有很多包含重復(fù)代碼的構(gòu)造函數(shù)時，可以把構(gòu)造函數(shù)鏈接起來，從而獲得最少的代碼重復(fù)。

11.2 統(tǒng)一接口

  當(dāng)需要一個與其子類具有相同接口的超類或接口時，可以找到所有子類含有而超類沒有的公共方法，把這些方法復(fù)制到超類中，并修改每個方法，使其執(zhí)行空行為。

11.3 提取參數(shù)

  當(dāng)一個方法或構(gòu)造函數(shù)將一個字段賦值為一個局部實例化的值時，可以把賦值聲明的右側(cè)提取到一個參數(shù)中，并通過客戶代碼提供的參數(shù)對字段進行賦值。

  本文關(guān)鍵詞：重構(gòu)與模式，由筆耕文化傳播整理發(fā)布。

本文編號：73368