學習重構(4)-重新組織數據

来源:https://www.cnblogs.com/youknowzcm/archive/2019/11/05/11797619.html

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 而帶來的額外複雜性。


您的分享是我們最大的動力!

更多相關文章
  • 場景 Ubuntu Server 16.04 LTS上怎樣安裝下載安裝Nginx並啟動: https://blog.csdn.net/BADAO_LIUMANG_QIZHI/article/details/102828075 Nginx的配置文件位置以及組成部分結構講解: https://blog. ...
  • 添加依賴 <dependency> <groupId>io.netty</groupId> <artifactId>netty-all</artifactId> <version>4.1.2.Final</version> </dependency> <dependency> <groupId>or ...
  • 場景 Ubuntu Server 16.04 LTS上怎樣安裝下載安裝Nginx並啟動: https://blog.csdn.net/BADAO_LIUMANG_QIZHI/article/details/102828075 Nginx的配置文件位置以及組成部分結構講解: https://blog. ...
  • 文章主人公:小明,就職於某互聯網公司,從事後端開發工作。最近小明收到通知公司需要開發一款《證件照》應用,需要徵集架構方案,主要功能包括: 小明雖然從事後端開發工作,但是一直很關註架構這方面的知識,以往都是開發大佬們架構好的應用現在有機會自己去實踐下,打算把自己學到的知識應用於實際案例中來。 小明的腦 ...
  • GoF設計模式一共有23個。一般可以按目的和作用範圍來進行劃分,具體劃分方法如下: 第一,這些模式按目的(即完成什麼樣任務)來劃分為創建型、結構型和行為型這三種模式: 創建型:用來創建對象。單例、原型、抽象工廠、建造者、工廠方法這五個都屬於這一分類。這種類別起到了將對象的創建與其使用進行分離解耦。 ...
一周排行
x