本文微信公眾號「AndroidTraveler」首發。

背景

最近在看《設計模式之禪》，為了能夠更加深入的理解設計模式，達到學以致用。
這邊記錄一下自己的一些感受和看法，並結合具體程式碼實戰來進行說明。

模板方法模式

但凡和設計模式掛上鉤，我們總是會覺得「高不可攀」。
然而實際上，設計模式是基於大量實際程式碼的經驗總結，它來自於實際的程式碼。
與其說「高不可攀」，其實它反而是比較「接地氣」。
而模板方法模式相信你看完本篇文章之後，會發現，原來這就是模板方法模式，然後就去看你之前的程式碼了。

小例子初識模板方法模式

理解設計模式最好的方法就是通過專案開發中的實際場景來說明。

大家做 Android 開發的時候寫 Activity 應該都會看到下面類似程式碼吧？

private void getIntents() {
    // 從 Intent 獲取傳遞過來的一些引數，設定到屬性中
}

private void findViewById() {
    // 通過 findViewById 來初始化各個元件
}

private void setViews() {
    // 給元件設定監聽或者初始狀態
}

假設我每個介面都這樣寫，那麼重複程式碼太多了，很沒必要。
雖然每個方法具體的邏輯不一樣，但是都有這些操作。

這個時候我們第一個想法就是繼承，抽取出一個 BaseActivity。
然後將這些通用程式碼都放到了 BaseActivity 裡面，子類再來覆寫就可以了。

但是還有一個問題，那就是，我每次都需要寫下面程式碼：

getIntents();
findViewById();
setViews();

尤其是通用程式碼多的時候，有時候手誤可能導致某些介面這三個方法呼叫順序還不一樣。
那怎麼辦呢？我們可以抽取出一個方法，這個方法代表了這三個方法統一的呼叫順序，這樣就不怕手誤寫錯了。
而這個方法就是我們的模板方法。

public abstract class BaseActivity extends Activity {
    /**
     * 從 Intent 獲取傳遞過來的一些引數，設定到屬性中
     */
    protected abstract void getIntents();

    /**
     * 通過 findViewById 來初始化各個元件
     */
    protected abstract void findViewById();

    /**
     * 給元件設定監聽或者初始狀態
     */
    protected abstract void setViews();

    /**
     * 模板方法
     */
    final public void init() {
        getIntents();
        findViewById();
        setViews();
    }
}
 

這樣我後面的 Activity 都可以繼承這個 BaseActivity，然後只需要呼叫 init 方法即可。
至於不同的 Activity 的邏輯我再在三個方法裡面各自實現即可。

鉤子方法

一聽到這個詞，是不是覺得有點「高大上」，似乎很 NB？
然而，聽完我後面的講述，你內心估計

我們上面的方法裡面，並不是所有的 Activity 都有其他 Activity 傳遞資料過來的，因此 getIntents 這個方法不一定所有子類都要呼叫。
這個時候我們可以提供一個鉤子方法，改動部分程式碼如下：

/**
 * 模板方法
 */
final public void init() {
    if (isGetIntents()) {
        getIntents();
    }
    findViewById();
    setViews();
}

/**
 * 鉤子方法，是否需要設定資料，預設為 true
 * @return
 */
protected boolean isGetIntents() {
    return true;
}

可以看到，通過鉤子方法，當我們預設需要獲取資料時，什麼都不用改動，如果我們不需要獲取資料，只需要覆寫我們的鉤子方法 isGetIntents 並返回 false 即可。

好了，有了初步的印象之後，接下來就正式的加深瞭解吧。

定義

Define the skeleton of an algorithm in an operation, deferring some steps to subclasses. Template Method lets subclasses redefine certain steps of an algorithm without changing the algorithm's structure.
定義一個操作中的演算法的框架，而將一些步驟延遲到子類中。使得子類可以不改變一個演算法的結構即可重定義該演算法的某些特定步驟。

簡單的說就是父類定義了一個模板方法，在這個模板方法裡面有一些特定的步驟。具體的步驟實現留給子類去處理。

父類的模板方法保持了各個子類的共性，模板方法裡面的步驟使得每個子類都有自己的個性。

通用程式碼實現

父類：

public abstract class AbstractPatternClass {
    /**
     * 基本方法，模板方法裡面呼叫
     */
    protected abstract void firstModule();
    /**
     * 基本方法，模板方法裡面呼叫
     */
    protected abstract void secondModule();

    /**
     * 模板方法，多個基本方法組合
     */
    final public void templateMethod() {
        firstModule();
        secondModule();
    }
}

具體子類：

public class ConcreteClass extends AbstractPatternClass {
    @Override
    protected void firstModule() {
        // TODO 子類實現自己的邏輯
    }

    @Override
    protected void secondModule() {
        // TODO 子類實現自己的邏輯
    }
}

場景使用類：

public class PatternTest {
    public static void main(String[] args) {
        AbstractPatternClass abstractPatternClass = new ConcreteClass();
        // 呼叫模板方法
        abstractPatternClass.templateMethod();
    }
}

鉤子方法我們上面已經說過了，相信聰明的你知道如何使用，這裡就不再贅述了。

注意點

父類中的基本方法儘量設計為 protected 型別，符合迪米特法則。
父類中的模板方法一般設定為 final，不允許子類覆寫。這樣的目的一個是為了避免子類惡意操作，一個是為了模板的共性。

應用

當你在寫程式碼經常用到複製和貼上快捷鍵時，你就要考慮是不是可以進行抽取。
當你修改一個地方的時候，發現其他地方也要連帶修改，也需要考慮一下。
多個子類有公共方法，並且邏輯基本相同。
複雜的一些演算法之類的，可以讓子類通過基本方法傳遞一些引數，核心邏輯放在模板方法裡面。
重構專案的時候，也可以考慮一下把相同程式碼抽取到父類，通過鉤子方法定製化模板。

結語

最後一點就是注意不要濫用設計模式，不要為了設計而設計

參考資料：
設計模式之禪（第2版）

相關推薦