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 而帶來的額外復雜性，
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/39833.html
標籤：架構設計
上一篇：如何讓多個不同型別的后端網站用一個nginx進行反向代理實際場景分析
下一篇：Netty實作遠程呼叫RPC功能