設計模式——裝飾模式

裝飾模式

定義

裝飾者模式又稱爲包裝(wrapper)模式。裝飾者模式對客戶端透明的方式擴展對象的功能，是繼承關係的一個替代方案。

模板

抽象構件(Component)角色：給出一個抽象接口，以規範準備接受附加責任的對象。
　具體構件(ConCreteComponent)角色：定義一個將要接受附加責任的類。
裝飾(Decorator)角色：持有一個構件(Component)對象的實例，並定義一個與抽象構件接口一致的接口。
　具體裝飾(ConcreteDecorator)角色：負責給構件對象「貼上」附加的責任。

實例

a) 客戶端埋點：常常將回調接口再包裝一層，在包裝層完成埋點或者其它非主功能的輔助代碼
例： 對下載回調listener包裝一層，進行下載的埋點。

b) 添加額外的輔助功能： 某個異步回調接口，可能出現回調收不到的bug，這時想設計一種 帶自動超時功能的回調：
// 原listener

public interface IListener<T> {
    void onSuccess(T result);
    void onError(String errorCode, String errorDesc);
}

// 帶自動超時功能的listener

public class AutoTimeoutResultListener<T> extends AbstractAutoTimeout
        implements IListener<T> {

    private IListener<T> mListener;

    public AutoTimeoutResultListener(IListener<T> listener) {
        mListener = listener;
    }

    @Override
    public synchronized void onSuccess(T result) {
        mListener.onSuccess(result);
    }

    @Override
    public synchronized void onError(String errorCode, String errorDesc) {
       mListener.onError(errorCode, errorDesc);
    }

    @Override
    synchronized void onTimeout() {
        mListener.onError(Constants.ERROR_CODE_TIME_OUT, "IListener time out.");
    }
}

裝飾模式的簡化：

(1) 只有一個ConcreteComponent時，能夠考慮去掉抽象的Component類，把Decorator做爲ConcreteComponent的子類。

(2) 若是隻有一個ConcreteDecorator類，能夠將Decorator類和ConcreteDecorator的責任合成一個類。

透明性要求：
裝飾模式對客戶端的透明性要求程序不要聲明Decorator類型的變量，而應該聲明Component接口變量。

半透明的裝飾模式：
純粹的裝飾模式已經很難找到了，裝飾模式的用意是在不改變接口的前提下，加強類的性能。在加強性能時，須要創建新的方法，可是純粹的裝飾模式沒法經過Component調用新創建的方法，這時候須要破壞透明性，才能使用新方法。

半透明的裝飾模式是介於裝飾模式和適配器模式之間的，裝飾模式和適配器模式都是「包裝模式」，它們都經過封裝其餘的對象達到設計的目的，可是邢臺有很大區別。

理想的裝飾模是在被裝飾對象進行功能加強時，要求具體的構件角色、裝飾角色的接口和抽象構件角色的接口徹底一致。而適配器並不要求對原對象進行加強，但會改變對象的接口，以便和目標接口相符合。

優勢

1. 對原有代碼的侵入性很小，能夠在不改變原有代碼結構的同時增長新的功能，如遇到緊急上線等狀況不失爲一種好的解決方法。
2. 能夠在裝飾類中增長新的功能/加強原有的功能，也符合職責單一原則，裝飾類專門作某種處理（埋點/超時處理）

缺點

1. 增長新的類
2. 多層裝飾比較複雜，影響代碼的維護及可讀性

適用場景

1. 需求開發緊急，添加新功能
2. 普通的添加新功能也能夠使用該種方法

其它實例：