1. Self Encapsulate Field（自封裝值域） 你直接訪問一個值域，但與值域之間的耦合關係逐漸變得笨拙。為這個值域建立取值/設值函數（get/set），並且只以這些函數來訪問值域。 應用場景：如果你想訪問superclass中的一個值域，卻又想在subclass中將[對這個變數的訪 ...
1. Self Encapsulate Field（自封裝值域）
你直接訪問一個值域，但與值域之間的耦合關係逐漸變得笨拙。為這個值域建立取值/設值函數（get/set），並且只以這些函數來訪問值域。
應用場景：如果你想訪問superclass中的一個值域，卻又想在subclass中將[對這個變數的訪問]改為一個計算後的值，這就是最該使用Self Encapsulate Field（171）的時候。[值域自我封裝]只是第一步。完成自我封裝之後，你可以在subclass中根據自己的需要隨意覆寫取值/設值函數（getting/setting methods）。
示例：
private int _low, _high
boolean includes (int arg) {
return arg >= _low && arg <= _high;
}
重構為：
private int _low, _high
boolean includes (int arg) {
return arg >= getLow() && arg <= getHigh();
}
int getLow() {return _low};
int getHigh() {return _high};
2. Replace Data Value with Object（以對象取代數據值）
將一些數據按照一定的規則或特征整合到一個對象中
應用場景：開發代碼初期，僅需要一些簡單的數據，比如一個人的基本信息：姓名，身份證號碼，隨著時間的推移，還需要其他的數據：手機號，地址，學歷等等，這樣就會羅列一排的變數，每次處理一個人的數據是，要傳入很多參數。此時將這個人的信息就可以規整到一個類裡面，僅聲明一個對象即可，而且隨著這個人信息的持續豐富，不會每次都衝擊到原有的介面。
3. Change Value to Reference（將實值對象改為引用對象）
你有一個class，衍生出許多相等的實體，你希望將他們替換為單對象。將這個實值對象變成一個引用對象。
應用場景：我們一般使用一個類的時候都是需要了就new一個對象出來，這些每次new出來的對象就是實值對象，但很多場景下我們會改變這些對象的內部狀態，並且需要對這些對象進行傳遞，此時用實值對象來滿足這個訴求就會顯得非常笨拙，比如new出來一個car，然後設置下品牌是寶馬，設置下顏色是藍色等等。這種場景下我們就需要一個引用對象，同一個類中可以是成員變數，不同的類中使用可以使用類似工廠、單例等模式來有一個對象管理類來供其他類取用。
4. Change Reference to Value（將引用對象改為實值對象）
和3相反。
應用場景：實值對象一個重要特點是保持不變，這樣可以保證每個使用者不用擔心數據的變化和同步。引用對象往往會讓邏輯變得複雜，所以使用的時候要做好選擇。
5. Replace Array with Object（以對象取代數組）
以對象替換數組，對於數組中的每個元素，以一個值域表示。
應用場景：數組是一種常見的用於組織數據的結構體。不過它們應該只用於以某種順序容納一組相似對象。有時候你會發現，一個數組容納了數種不同對象，這會給數組用戶帶來麻煩，因為它們很難記住像“數組的第一個元素是人名“這樣的約定。對象就不一樣。可以通過命名和函數來傳遞一些信息。讓使用者更容易理解。
示例：
String[] row = new String[3];
row[0] = "Liverpool";
row[1] = "15";
重構為：
Performance row = new Performance();
row.setName("Liverpool");
row.setWins("15");
6. Duplicate Observed Data（賦值“被監視數據”）
你有一筆domain data置身於GUI空間中，而domain method需要訪問它們。將這筆數據拷貝到一個domain object中，建立一個Observer模式，用意對domain object和GUI object內的重覆數據進行同步控制。
應用場景：一個分層良好的系統，應該將處理用戶界面和處理業務邏輯的代碼分開。之所以這樣做，原因有一下幾點：（1）你可能需要使用不同的用戶界面來表現相同的業務邏輯，如果同時承擔兩種責任，用戶界面會變得過分複雜；（2）與GUI隔離後，領域對象的維護和演化都會更容易，甚至可以讓不同的開發者負責不同部分的開發。儘管可以輕鬆地將“行為”劃分到不同部位，“數據”卻往往不能如此。同一項數據有可能既需要內嵌於GUI控制項，也需要保存於領域模型里。自從MVC模式出現後，用戶界面框架都是用多層系統來提供某種機制，使你不但可以提供這類數據，並保持他們同步。如果代碼是以兩層方式開發，業務邏輯被內嵌於用戶界面之中，就有必要將行為分離出來。其中的主要工作就是函數的分解和搬移。但數據就不同了：不能僅僅只是移動數據，必須將它複製到新對象中，並提供相應的同步機制。
7. Change Unidirectional Association to Bidirectional（將單項關聯改為雙向）
兩個classes都需要使用對方特性，但其間只有一條單向連接。添加一個反向指針，並使修改函數能夠同時更新兩條連接。
應用場景：開發初期，你可能會在兩個classes之間建立一條單向連接，使其中一個class可以引用另一個class。隨著時間的推移，你可能發現被引用的class需要得到其引用者來進行某些處理，也就是說它需要一個反向指針。
8. Change Bidirectional Association to Unidirectional（將雙向關聯改為單向）
應用場景：雙向關聯很有用，但你也必須為它付出代價，那就是“維護雙向連接，確保對象被正確的創建和刪除”而增加的複雜度。所以只有在你需要雙向關聯的時候，才應該使用它。如果你發現雙向關聯不再有存在價值，就應該去掉其中不必要的一條關聯。
9. Replace Magic Number with Symbolic Constant（以符號常量/字面常量取代魔法數字）
應用場景：在計算科學中，魔法數（magic number）是歷史最悠久的不良現象之一。所謂魔法數是指擁有特殊意義，卻又不能明確表現出這種意義的數字。如果你需要在不同的地點引用同一個邏輯數，魔法數會讓你煩惱不已，因為一旦這些數發生改變，你就必須在程式中找到所有魔法數，並將它們全部修改一遍，這簡直就是一場噩夢。就 算你不需要修改，要準確指出每個魔法數的用途，也會讓你頗費腦筋。許多語言都允許你聲明常量。常量不會造成任何性能開銷，卻可以大大提高代碼的可讀性。進行本項重構之前，你應該先尋找其他替換方案。你應該觀察魔法數如何被使用，而後往往你會發現一種更好的使用方式。如果這個魔法數是個type code（型別碼）， 請考慮使用Replace Type Code with Class；如果這個魔法數代表一個數組的長度，請在遍歷該數組的時候，改用Array.length()。
10. Encapsulate Field（封裝值域）
能理解和第一條“自封裝值域”的區別嗎？
應用場景：面向對象的首要原則之一就是封裝（encapsulation），或者稱為「數據隱藏」（data hidding）。按此原則，你絕不應該將數據聲明為public，否則其他對象就有可能訪問甚至修改這項數據，而擁有該數據的對象卻毫無察覺。這就將數據和行為分開了（不妙）。public 數據被看做是一種不好的作法，因為這樣會降低程式的模塊化程度（modularity）。如果數據和使用該數據的行為被集中在一起，一旦情況發生變化，代碼的修改就會比較簡單，因為需要修改的代碼都集中於同一塊地方，而不是星羅棋佈地散落在整個程式中。Encapsulate Field是封裝過程的第一步。通過這項重構手法，你可以將數據隱藏起來，並提供相應的訪問函數（accessors）。但它畢竟只是第一步。如果一個class除了訪問函數（accessors）外不能提供其他行為，它終究只是一個dumb class (啞類〕。這樣的class並不能獲得對象技術的優勢，而你知道，浪費任何一個對象都是很不好的。實施Encapsulate Field之後，我會嘗試尋找那些使用「新建 訪問函數」的函數，看看是否可以通過簡單的Move Method 輕快地將它們移到新對象去。
11. Encapsulate Collection（封裝群集）
應用場景：class常常會使用群集（collection，可能是array、list、set或vector）來保存一組實體。這樣的class通常也會提供針對該群集的「取值/設值函數」（getter/setter）。但是，群集的處理方式應該和其他種類的數據略有不同。取值函數（getter）不該返回群集自身，因為這將讓用戶得以修改群集內容而群集擁有者卻一無所悉。這也會對用戶暴露過多「對象內部數據結構」的信息。如果一個取值函數（getter）確實需要返回多個值，它應該避免用戶直接操作對象內所保存的群集，並隱藏對象內「與用戶無關」的數據結構。至於如何做到這一點，視你使用的版本不同而有所不同。另外，不應該為這整個群集提供一個設值函數（setter），但應該提供用以為群集添加/移除（add/remove）元素的函數。這樣，群集擁有者（對象）就可以控制群集元素的添加和移除。如果你做到以上數點，群集（collection）就被很好地封裝起來了，這便可以降低群集擁有者（class）和用戶之間的耦合度。
12. Replace Record with Data Class（以數據類取代記錄）
應用場景：Record structures （記錄型結構）是許多編程環境的共同性質。有一些理由使它們被帶進面向對象程式之中：你可能面對的是一個老舊程式（ legacy program ），也可能需要通過一個傳統API 來與structured record 交流，或是處理從資料庫讀出的 records。這些時候你就有必要創建一個interfacing class ，用以處理這些外來數據。最簡單的作法就是先建立一個看起來類似外部記錄（external record）的class ，以便日後將某些值域和函數搬移到這個class 之中。一個不太常見但非常令人註目的情況是：數組中的每個位置上的元素都有特定含義，這種情況下你應該使用Replace Array with Object 。
13. Replace Type Code with Class（以類取代型別碼）
應用場景：在以C 為基礎的編程語言中，type code（型別碼）或枚舉值（enumerations）很常見。如果帶著一個有意義的符號名，type code 的可讀性還是不錯的。問題在於，符號名終究只是個別名，編譯器看見的、進行型別檢驗的，還是背後那個數值。任何接受type code 作為引數（argument）的函數，所期望的實際上是一個數值，無法強制使用符號名。這會大大降低代碼的可讀性，從而成為臭蟲之源。如果把那樣的數值換成一個class ，編譯器就可以對這個class 進行型別檢驗。只要為這個class 提供factory methods ，你就可以始終保證只有合法的實體才會被創建出 來，而且它們都會被傳遞給正確的宿主對象。但是，在使用Replace Type Code with Class 之前，你應該先考慮type code 的其他替換方式。只有當type code 是純粹數據時（也就是type code 不會在switch 語句中引起行為變化時），你才能以class 來取代它。Java 只能以整數作為switch 語句的「轉轍」依據，不能使用任意class ，因此那種情況下不能夠以class 替換type code 。更重要的是：任何switch 語句都應該運用 Replace Conditional with Polymorphism 去掉。為了進行那樣的重構，你首先必須運用 Replace Type Code with Subclasses 或Replace Type Code with State/Strategy 把type code處理掉。即使一個type code 不會因其數值的不同而引起行為上的差異，宿主類中的某些行為還是有可能更適合置放於type code class 中，因此你還應該留意是否有必要使用Move Method 將一兩個函數搬過去。
14. Replace Type Code with Subclasses（以子類取代型別碼）
應用場景：如果你面對的type code 不會影響宿主類的行為，你可以使用Replace Type Code with Class 來處理它們。但如果type code 會影響宿主類的行為，那麼最好的辦法就是藉助多態（polymorphism ）來處理變化行為。一般來說，這種情況的標誌就是像switch 這樣的條件式。這種條件式可能有兩種表現形式：switch 語句或者if-then-else 結構。不論哪種形式，它們都是檢查type code 值，並根據不同的值執行不同的動作。這種情況下你應該以Replace Conditional with Polymorphism 進行重構。但為了能夠順利進行那樣的重構，首先應該將type code 替換為可擁有多態行為的繼承體系。這樣的一個繼承體系應該以type code 的宿主類為base class，並針對每一種type code 各建立一個subclass 。為建立這樣的繼承體系，最簡單的辦法就是Replace Type Code with Subclasses：以type code 的宿主類為base class，針對每種type code 建立相應的subclass 。 但是以下兩種情況你不能那麼做：(1) type code 值在對象創建之後發生了改變；(2) 由於某些原因，type code 宿主類已經有了subclass 。如果你恰好面臨這兩種情況之一，就需要使用Replace Type Code with State/Strategy 。Replace Type Code with Subclasses 的主要作用其實是搭建一個舞臺，讓Replace Conditional with Polymorphism 得以一展身手。如果宿主類中並沒有出現條件式，那麼 Replace Type Code with Class 更合適，風險也比較低。使用Replace Type Code with Subclasses 的另一個原因就是，宿主類中出現 了「只與具備特定type code 之對象相關」的特性。完成本項重構之後，你可以使用 Push Down Method 和 Push Down Field 將這些特性推到合適的subclass去，以彰顯它們「只與特定情況相關」這一事實。Replace Type Code with Subclasses 的好處在於：它把「對不同行為的瞭解」從class 用戶那兒轉移到了class 自身。如果需要再加入新的行為變化，我只需添加subclass 一個就行了。如果沒有多態機制，我就必須找到所有條件式，並逐一修改它們。因此，如果未來還有可能加入新行為，這項重構將特別有價值。
15. Replace Type Code with State/Strategy（以State/strategy 取代型別碼）
應用場景：本項重構和Replace Type Code with Subclasses 很相似，但如果「type code 的值在對象生命期中發生變化」或「其他原因使得宿主類不能被subclassing 」，你也可以使用本重構。本重構使用State 模式或Stategy 模式[Gang of Four]。State 模式和Stategy 模式非常相似，因此無論你選擇其中哪一個，重構過程都是相同的。「選擇哪一個模式」並非問題關鍵所在，你只需要選擇更適合特定情境的模式就行了。如果你打算在完成本項重構之後再以 Replace Conditional with Polymorphism 簡化一個演算法，那麼選擇Stategy 模式比較合適；如果你打算搬移與狀態相關（state-specific）的數據，而且你把新建對象視為一種變遷狀態 （changing state），就應該選擇使用State 模式。
16. Replace Subclass with Fields（以值域取代子類）
應用場景：建立subclass 的目的，是為了增如新特性，或變化其行為。有一種變化行為（variant behavior ）稱為「常量函數」（constant method）[Beck]，它們會返回一個硬編碼 （hard-coded）值。這東西有其用途：你可以讓不同的subclasses 中的同一個訪問函數（accessors）返回不同的值。你可以在superclass 中將訪問函數聲明為抽象函數， 併在不同的subclass 中讓它返回不同的值。儘管常量函數有其用途，但若subclass 中只有常量函數，實在沒有足夠的存在價值。 你可以在中設計一個與「常量函數返回值」相應的值域，從而完全去除這樣的subclass 。如此一來就可以避免因subclassing 而帶來的額外複雜性。
