重構-改善既有代碼的設計(三)--代碼的壞味道

壞味道的代碼

重複代碼

idea會自動標註重複的代碼。通常重複代碼就是能夠重構的點。

1. 同一個類的兩個函數還有相同的表達式，這時須要提煉出重複代碼。
2. 兩個互爲兄弟的子類內含有相同的表達式，能夠提煉相同代碼，並放到父類中。
3. 若是兩個絕不相關的類中出現重複代碼，則能夠將重複代碼提煉成一個函數放到一個獨立類中或者只放在某一個類中（總之要放在合適的地方），而後其餘類都去調用這個函數。

過長函數

過長的函數。每每表明着功能複雜。可讀性差。複用概率低
遵循一個原則,一個函數要儘可能短。並以做用命名

過大的類

保證每一個類都只作一件事

過長參數列：用對象作參數來減小參數個數

這個我以爲不須要提出來。由於公司一直都是用對象來做爲參數的。

發散式變化：添加或修改功能都只改一個類

能夠將這個類分爲多個類。可是這個狀況不容易發現。通常都是遇到真實狀況後才考慮獲得

霰彈式修改：添加或修改一個功能引起多個類相應修改

遇到這種狀況能夠移動代碼，將須要修改的代碼都放在同一個類下。假如沒有這樣的類，能夠建立一個

依戀情節：一個方法可能會調用多個類的多個數據或方法。而不多調用本類的數據或方法

若是該方法只調用了一個類的多個方法。將該方法移到調用類裏。
若是該方法調用了多個類的多個方法。將該方法拆解。而後分離到調用類裏。

數據泥團：老是綁在一塊兒的數據應該擁有屬於它們本身的對象

對於老是成堆出現的數據應該封裝成一個對象。好比方法參數，就能夠封裝成對象

switch語句

看到switch語句直接就用多態替換。switch原本就是一種重複的語句

冗贅類

若是項目中有沒用的類

誇誇其談將來性

咱們將來必定會作這件事。可是如今用不上。就不必如今就加上各類特殊狀況考慮。作到留有餘地就好
好比一個類或方法的惟一服務對象是是測試用例。能夠將測試用例和類一併刪掉。若是是幫助測試用例獲得正確的結果。則能夠保留

使人迷惑的臨時字段

類中的某個變量可能只針對某種特殊狀況。但閱讀該代碼你會認爲這是一般使用的變量。因此額外建立一個類存放該變量

過分耦合的消息鏈

消息鏈的定義：a對象調用b對象,b對象調用c對象，。。。。這樣就造成了消息鏈
假如a對象發生了變化。
注：不是全部的消息鏈都是很差的。具體狀況具體分析
解決方法：

class Person {
    Department _department;

    public Department getDepartment(){
        return _department;
    }

    public void setDepartment (Department arg){
        _department = arg;
    }
    
}

class Department{
    private String _chargeCode;
    private Person _manager;

    public Department (Person manager){
        _manager = manager;
    }

    public Person getManager{
        return _manager;
    }

}

若是客戶但願知道某人的經歷是誰, 他必須先得到Department對象:

manager = john.getDepartment().getManager();

這樣的編碼就對客戶端揭露了Department的工做原理, 因而客戶知道:Department用以追蹤"經理" 這條信息. 若是對客戶端隱藏Department, 能夠減小耦合. 爲了這一目的, 我在Person中創建一個簡單的委託函數:

public Person getManager(){
    return _department.getManager();
}

如今,我須要修改Person的全部客戶, 讓它們改用新函數:

manager = john.getManager();

只要完成了對Department全部函數的委託關係, 並相應修改了Person的全部客戶, 我就能夠移除Person中的訪問函數getDepartment()函數了

中間人

狎暱關係

殊途同歸的類

若是兩個方法作着同一件事，但方法名不同。就要考慮從新更名字了

不完美的類庫

若是底層的類庫不能知足開發的須要。就用外部方法封裝該方法，並添加相關邏輯

純稚的數據類

純稚的數據類（model）是指：它們擁有一些字段，以及用於訪問（讀寫）這些字段的函數，除此以外一無長物。
這種類若是get/set方法均是public的，則須要引發注意，應該進行適當的封裝，而不是所有公有化。

被拒絕的遺贈

子類應該繼承超類的函數和數據。但若是他們不想或不須要繼承全部的函數和數據，則應該爲這個子類新建一個兄弟類，把全部用不到的函數和數據放到兄弟類中，他們共享的數據和函數則放到共同的超類中。

過多的註釋

當你感受須要撰寫註釋時，請先嚐試重構，試着讓全部註釋都變得多餘