策略模式 (Strategy Pattern)

        假設你在公司做了一套鴨子遊戲, 類別圖如下:

        某天, 主管要求你把這遊戲加上新功能: 讓鴨子會飛, 這時程式要怎麼修改呢? 最簡單的方式, 就是在父類別裡加一個 method: fly(), 這樣就所有的鴨子都會飛啦。但是這樣好像怪怪的，因為並不是每種鴨子都會飛。就算把不會飛的鴨子 fly() 裡什麼事都不做, 未來當不會飛的鴨子越來越多, 程式維護起來也很麻煩。

        既然繼承不行，那改成介面(Interface) 應該可以吧 ?  因為不是所有鴨子都會飛跟叫, 因此就把這兩個行為拉出來變 Interface, 其類別圖如下:

        但是這也不是個好的方法。一來程式碼無法再利用, 二來當鴨子的種類變多時, 每種鴨子都要自己實作 Flyable 或 Quackable, 而這時候策略模式就派上用場了。

        定義: 策略模式 定義了演算法家族, 個別封裝起來,  讓它們之間可以互相替換。此模式讓演算法的變動, 不會影響到使用演算法的程式。
Define a family of algorithms, encapsulate each one, and make them interchangeable. Strategy lets the algorithm vary independently from clients that use it. 

        設計守則:
        1. 把程式中可能變動的部份獨立出來
        2. 寫程式是針對介面寫, 不是針對實作方式寫
        3. 多用合成, 少用繼承

        根據守則1, 我們知道目前會變動的就是飛跟叫的行為, 而這兩個行為在上個類別圖已經獨立出來了。根據守則2, 第一版的鴨子程式, 因為功能都加在 Duck 裡, 造成程式沒有彈性, 因此要有其他類別來實作 Flyable 跟 Quackable。更精確一點的說, 是指 Duck 想要有飛或叫的行為, 其變數的宣告應該是抽象類別或介面, 如此可使用多型, 在執行時可以依據不同的實作而執行不同的行為(不懂的話自行複習多型的觀念)。

        由設計守則1 2, 我們可以重新設計這個鴨子遊戲了。當有需要飛的行為時, 就產生飛的類別, 去實作 Flyable, 同理需要叫的行為也是一樣, 其類別圖如下:

        需要用翅膀飛的鴨子就可以用 FlyWithWings, 而不會飛的鴨子就能用 FlyNoWay。

        同理, 會呱呱叫的鴨子就用 Quack, 不會叫的用 MuteQuack。

        這樣的設計, 可以讓飛跟叫的行為被其他鴨子物件再利用, 因為這些行為跟鴨子類別沒關係了。就算我們再新增其他飛或叫的行為，也不會影響到鴨子類別。而修改過後的 Duck class 類別圖如下:

        接下來就是看程式碼了~

public abstract class Duck {

    Flyable flyAble;
    Quackable quackAble;

    public abstract void display();

    public void performFly()
    {
        if(flyAble != null)
            flyAble.fly();
    }

    public void performQuack()
    {
        if(quackAble != null)
            quackAble.quack();
    }

    public void setFlyable(Flyable fly)
    {
        flyAble = fly;
    }

    public void setQuackable(Quackable quack)
    {
        quackAble = quack;
    }
}

假設我們今天有一隻超級鴨, 想要讓牠會超級飛跟超級叫, 程式如下:

public class SuperFly implements Flyable {

    public void fly()
    {
        System.out.println("I'm super flying!!");
    }
}

public class SuperQuack implements Quackable {

    public void quack()
    {
        System.out.println("I'm super quacking!!");
    }
}

public class SuperDuck extends Duck {

    public void display()
    {
        System.out.println("I'm super duck!!");
    }
}

public class DuckTest {

    pubilc static void main(String[] args)
    {
        Duck duck = new SuperDuck();

        // 指定這隻鴨怎麼飛
        duck.setFlyable(new SuperFly());

        // 指定這隻鴨怎麼叫
        duck.setQuackable(new SuperQuack());

        duck.performFly();
        duck.performQuack();
    }
}

        從程式碼可以看出, 未來超級鴨想要有其他不同行為的飛或叫時, 只要新增其類別, 在程式執行期間, 隨時可以更換。
     
        最後看一下加入策略模式後的鴨子類別圖吧:

        從最後的程式碼可以看出, 用合成建立系統有很大的彈性。不但可以把行為(演算法) 封裝成類別, 更可以在執行期間動態改變行為 (演算法), 只要合成的行為物件符合特定的介面即可。這也就是設計守則3 所說的: 多用合成, 少用繼承。




參考資料:

1. Head First Design Patterns (深入淺出設計模式)