用裝飾模式優化代碼的一個簡單例子

## 業務場景寫一個數據層的loader，loader的數據拉取有可能走本地或者走網路，所以肯定需要通過回調來返回數據，而且兩種情況在view層的表現不一樣（一個顯示載入框一個不顯示），也需要通過回調來告知。## 優化前最簡單的做法是寫一個這樣的介面，把所有可能要做的事情都各寫一個方法，比如這樣：`... ...

這個例子展示了對一處比較隱蔽的壞味道的優化，可能一不小心就被放任自流了，好在業務本身和優化前後的代碼都很簡單，適合作為一個工程實例寫出來給大家分享。

業務場景

寫一個數據層的loader，loader的數據拉取策略是本地有就走本地否則走網路，所以需要通過回調來返回數據，而且兩種情況在view層的表現不一樣（一個顯示載入動畫另一個不顯示），也需要通過回調來告知。

優化前

最簡單的做法是寫一個這樣的介面，把所有可能要做的事情都各寫一個方法，比如這樣：

public interface XXLoadAction<T> {
    void showLoadingView();
    void hideLoadingView();
    void onDataBack(T model);
}

這樣寫非常簡單直接，而且能用，但至少存在這麼幾個問題：

沒有錯誤處理 當有網路錯誤或者其他錯誤需要體現出來的時候，你只能通過擴展model來實現，而往往這種擴展會重覆出現，這樣便有可能造成大量重覆代碼
沒有擴展性 當前需求是在網路請求開始的時候顯示載入動畫，網路請求結束時隱藏載入動畫，但如果需求改變，需要在開始和結束的時候多做一些事情，你無法在這個action上進行擴展，只能把這些事情加在其他地方做，但這些事情本身跟load action聯繫非常緊密，這樣就會影響代碼的內聚性
耦合程度太高 loader是model層的東西，如果在load action中還有對view層直接的操作，知道也太多了

於是我設計了兩個介面來解決這些問題

耦合程度太高 抽象出耗時的概念，使用兩個介面來分別處理長時間和短時間的請求，model層通過判斷是否需要進行網路請求來選擇ShortLoadAction還是LongLoadAction，而不關心你在回調中要對view做什麼操作
沒有錯誤處理 、沒有擴展性 對於每個介面，都像網路請求一樣寫了4個回調，把跟具體實現有關的東西移除了，提高了基礎組件的可擴展性，同時增加常用錯誤處理回調和自定義錯誤處理回調

public interface ShortLoadAction<T> {
    void onStartShort();

    void onCancelShort();

    void onBrokenShort();

    void onCompleteShort(int stateCode, String stateMsg, T model);
}

public interface LongLoadAction<T> {
    void onStartLong();

    void onCancelLong();

    void onBrokenLong();

    void onCompleteLong(int stateCode, String stateMsg, T model);
}

你會發現這兩個介面方法類似但名字不一樣，因為我接下來寫了一個適配器，結合目前簡單的業務情況，為這兩個action做了一層封裝，方便view層或presenter層使用，這個適配器需要實現上面兩個介面，如果兩個介面方法名一樣就亂套了，所以雖然這樣有點怪，但也是沒有辦法

public abstract class LoadAction<T> implements ShortLoadAction<T>, LongLoadAction<T> {

    @Override
    public void onStartShort() {
        // do nothing
    }

    @Override
    public void onCancelShort() {
        onFailed();
    }

    @Override
    public void onBrokenShort() {
        onFailed();
    }

    @Override
    public void onCompleteShort(int stateCode, String stateMsg, T model) {
        onSuccess(model);
    }

    /*-------------------------------------------------*/

    @Override
    public void onStartLong() {
        showLoadingView();
    }

    @Override
    public void onCancelLong() {
        hideLoadingView();
        onFailed();
    }

    @Override
    public void onBrokenLong() {
        hideLoadingView();
        onFailed();
    }

    @Override
    public void onCompleteLong(int stateCode, String stateMsg, T model) {
        hideLoadingView();
        onSuccess(model);
    }

    /*--------------------------------------------------------------------------------------------*/

    public abstract void showLoadingView();

    public abstract void hideLoadingView();

    public abstract void onFailed();

    public abstract void onSuccess(T model);
}

有了這個抽象類，使用者只管實現載入動畫的顯示隱藏、處理成功失敗就行了，把擴展性強但略顯複雜的四個回調以及耗時長短的區分都隱藏起來不需要去關心。

為了進一步方便使用，我還通過ViewHelper（可以把它當成載入動畫的實現類）寫了一個用起來更簡單的adapter，這下使用者只需要關心成功失敗了：

public abstract class VHelperLoadAction<T> extends LoadAction<T> {
    private ViewHelper viewHelper;

    public VHelperLoadAction(ViewHelper viewHelper) {
        this.viewHelper = viewHelper;
    }

    @Override
    public void showLoadingView() {
        viewHelper.showLoadingView();
    }

    @Override
    public void hideLoadingView() {
        viewHelper.hideLoadingView();
    }
}

寫完一用感覺很不錯，完全沒有感覺不對或者是不符合設計模式什麼的，ShortLoadAction和LongLoadAction方法名的奇怪感覺早就忘得一干二凈。比如這是一處使用：

VHelperLoadAction<List<WordPage>> loadAction = new VHelperLoadAction<List<WordPage>>(vHelper) {
    @Override
    public void onFailed() {
        vHelper.toastNetworkBroken();
    }

    @Override
    public void onSuccess(List<WordPage> model) {
        CheckWordsActivity.start(getActivity(), model);
    }
};

pageWordsLoader.load(pages, loadAction, loadAction);

這個loader的主要load方法長這樣：

public void load(List<String> pageIds, ShortLoadAction<List<WordPage>> loadShortAction, LongLoadAction<List<WordPage>> loadLongAction) {
    this.pageIds = pageIds;
    dbHelper.createTableIfNotExist();

    List<String> unsavedPageNumbers = getUnSavedPageNumbers();
    if (unsavedPageNumbers.isEmpty()) {
        loadWordsFromLocal(loadShortAction, null);
    } else {
        loadWordsFromRemote(unsavedPageNumbers, loadLongAction);
    }
}

分析

這個代碼還給別人講過，講完都沒覺得有問題。直到一次codereview中，我剛跟老大解釋完這幾個action的關係，老大就表示這塊寫得不太好。

開始他是覺得後邊這個load()方法中需要傳兩個action進去非常奇怪，但我知道這塊沒有問題，因為loader的使用者是不知道也不應該關心到底選擇哪種action，loader應該自己去看本地有沒有數據，然後選擇short或者long的action。大家都同意這個觀點。

但還有一個同事認為只要把兩個action合成一個action一切就完美了。給每個回調方法增加一個參數：isLong，回調方法中就可以根據不同的參數來做不同的事，只需要傳入一個action，也沒有方法名啰嗦的問題。
但其實這個設計問題很多，至少有這兩個：

if else爆炸 本來只需要在上面那個load方法中做一次if else，在使用這種設計後你需要有幾個回調方法就加兩倍於此的if else，回調的調用處一次，回調的被調處一次

不便於擴展 假如有第三種action你是準備再加一種參數嗎？

然後我們老大就指出了這部分代碼的最大問題，在於ShortLoadAction和LongLoadAction倆個明顯有相似關係的東西居然沒有一點關係，是兩個完全不同的介面；同時，在loader的最裡層（關心選擇short或者long的action的裡層），本來可以不關心具體是short還是long的action，現在卻直接關心了（持有action的類型是ShortLoadAction或LongLoadAction：
loadWordsFromRemote(List<String> unsavedPageNumbers, LongLoadAction<List<WordPage>> loadLongAction) )

這個問題在被提出之後變得異常刺眼，但好像很好解決。讓他們實現自同一個介面就好了，但由於跟前面同樣的原因，好用的適配器LoadAction寫不出來。雖然這隻是個使用上的方便性問題，應該給設計的合理性讓位，但兩全其美還是最好的。
通過觀察發現LongLoadAction其實是在ShortLoadAction的基礎上進行了一些擴展，那麼就可以使用繼承，讓ShortLoadAction成為LongLoadAction的父類，這樣寫用起來也不會太麻煩。但只是這個原因並不足以讓我們使用繼承，由於眾所周知的原因，能使用組合的地方就不要用繼承，那麼對於這個場景，基於組合的裝飾模式就是最為合適的了，在使用的方便性和設計的合理性上都有很好的表現。

優化後

裝飾模式本身是實現起來非常簡單的一個模式，這裡我只需要寫一個介面同時作為被裝飾類和一個裝飾類就OK了

public interface LoadAction<T> {
    void onStart();

    void onCancel();

    void onBroken();

    void onComplete(int stateCode, String stateMsg, T model);
}

public abstract class WaitLoadAction<T> implements LoadAction<T> {
    private LoadAction<T> loadAction;

    private WaitLoadAction() {
    }

    public WaitLoadAction(LoadAction<T> loadAction) {
        this.loadAction = loadAction;
    }

    @Override
    public void onStart() {
        showLoadingView();
        loadAction.onStart();
    }

    @Override
    public void onCancel() {
        hideLoadingView();
        loadAction.onCancel();
    }

    @Override
    public void onBroken() {
        hideLoadingView();
        loadAction.onBroken();
    }

    @Override
    public void onComplete(int stateCode, String stateMsg, T model) {
        hideLoadingView();
        loadAction.onComplete(stateCode, stateMsg, model);
    }

    /*--------------------------------------------------------------------------------------------*/

    public abstract void showLoadingView();

    public abstract void hideLoadingView();
}

自然地我用ViewHelper簡化了WaitLoadAction

public class VHelperWaitLoadAction<T> extends WaitLoadAction<T> {
    private ViewHelper viewHelper;

    public VHelperWaitLoadAction(LoadAction<T> loadAction, ViewHelper viewHelper) {
        super(loadAction);
        this.viewHelper = viewHelper;
    }

    @Override
    public void showLoadingView() {
        viewHelper.showLoadingView();
    }

    @Override
    public void hideLoadingView() {
        viewHelper.hideLoadingView();
    }
}

這樣寫完感覺用的時候還是不很方便，我還得把LoadAction做一個封裝

public abstract class SimpleLoadAction<T> implements LoadAction<T> {
    @Override
    public void onStart() {
        // do nothing
    }

    @Override
    public void onCancel() {
        onFailed();
    }

    @Override
    public void onBroken() {
        onFailed();
    }

    @Override
    public void onComplete(int stateCode, String stateMsg, T model) {
        onSuccess(model);
    }

    /*--------------------------------------------------------------------------------------------*/

    public abstract void onFailed();

    public abstract void onSuccess(T model);
}

於是用的時候是這樣，一樣好用，還會更清晰，而且最初那個方法命名啰嗦的問題也沒有了：

LoadAction<List<WordPage>> loadAction = new SimpleLoadAction<List<WordPage>>() {
    @Override
    public void onFailed() {
        vHelper.toastNetworkBroken();
    }

    @Override
    public void onSuccess(List<WordPage> model) {
        CheckWordsActivity.start(getActivity(), model);
    }
};

pageWordsLoader.load(pages, loadAction, new VHelperWaitLoadAction<>(loadAction, vHelper));

總結

回過頭來看，優化前後雖然都是4個類，但顯然優化後減少了重覆的代碼，用這些省下來的空間分離了耦合，還進一步讓整個架構變得更加靈活，是一次比較成功的優化。

***
...
但後來發現我們的適配設備（是個專門給某個pad開發並且燒錄進去一塊出售的軟體）性能實在捉急，以至於在本地取數據花的時間也不短，所以需要跟網路請求一樣顯示載入動畫，於是最後我只用了一個VHelperWaitLoadAction（攤手）