策略模式 Strategy

介紹

在策略模式（Strategy Pattern）中，一個類的行為或其演算法可以在運行時更改，這種型別的設計模式屬于行為型模式，

在策略模式中，我們創建表示各種策略的物件和一個行為隨著策略物件改變而改變的 context 物件，策略物件改變 context 物件的執行演算法，

Intent

定義一系列演算法，封裝每個演算法，并使它們可以互換，

策略模式可以讓演算法獨立于使用它的客戶端，

前言

本篇會以一個飼養員的飼養作業為例，一步步碼到使用策略模式解決實際問題，

首先我們看看遇到類似如下的問題時，該怎么辦，

有多種類別的多個寵物需要喂食，
只有一個人（物件）知道不同寵物應該根據它的體重喂多少食物，

本篇文章部分參考：https://github.com/geekxh/hello-algorithm/blob/master/%E4%B8%93%E6%A0%8F/%E8%AE%BE%E8%AE%A1%E6%A8%A1%E5%BC%8F/%E7%AD%96%E7%95%A5%E6%A8%A1%E5%BC%8F.md

你可以在這篇文章里找到最簡潔的策略模式實作

一直膨脹的飼養員

最直接的實作方式，就是創建一個Feeder類（飼養員），在里面實作一個Feed喂食方法，然后在喂食時，根據寵物種類和體重決定喂食量，

public class Feeder {
    public void feed(Cat cat) {
        System.out.println("我喂食了" + cat.getName() + " " +                       getCatFoodAmount(cat) + "斤食物");
    }
?
    public Integer getCatFoodAmount(Cat cat) {
        Integer weight = cat.getWeight();
        return weight/2;
    }
?
    // 輸出結果
    // 我喂食了Tom 4斤食物
    public static void main(String[] args) {
        Cat tom = new Cat("Tom", 8);
        Feeder feeder = new Feeder();
        feeder.feed(tom);
    }
}

上面的代碼很直接，但是這樣做在拓展時就會出現問題了，如果飼養員以后要喂狗狗，要喂熊貓，要喂西幾，要喂腦斧，就得一直往Feeder類中寫入feed的多載方法和getXXXFoodWeight方法，飼養員類就逐漸變成了個胖子，太不優雅了，

那么如何解決飼養員日益膨脹問題 ??？

讓動物說話

首先我們把計算的方法交給寵物自己，

寵物不會說話，但是他們會吃東西，而且知道自己最多能吃多少（理想情況），

所以，讓寵物（類）告訴我們能吃多少就可以了，不需要讓飼養員自己去算，

public class Cat {
    /** 名字 */
    private String name;
?
    /** 體重，斤 */
    private Integer weight;
?
    public Cat(String name, Integer weight) {
        this.name = name;
        this.weight = weight;
    }
?
    /** 計算食量 */
    public Integer getMaxFoodAmount() {
        return this.weight/2;
    }
    // 隱藏了getter setter
}

這樣我們就可以幫feeder減肥了！

public class Feeder {
    // cat.getFoodWeight() 貓咪已經知道自己要吃多少了！
    public void feed(Cat cat) {
        System.out.println("我喂食了" + cat.getName() + " " +                       cat.getMaxFoodAmount() + "斤食物");
    }
}

一視同仁

還有一個問題需要解決，飼養員喂狗狗，還要多載feed，也就是說，喂狗狗的姿勢還跟喂貓咪的姿勢不太一樣，拓展起來也不優雅，他們明明都是寵物對吧，

飼養員應該要學會一視同仁，

他們都有同樣的屬性

我們把貓貓狗狗抽象出來一個類Animal，他們有名字，體重2個共通屬性，

那么Animal的設計就有了

public abstract class Animal implements Feedable {
    /** 名字 */
    private String name;
?
    /** 體重，斤 */
    private Integer weight;
?
    public String getName() {return name;}
?
    public void setName(String name) {this.name = name;}
?
    public Integer getWeight() {return weight;}
?
    public void setWeight(Integer weight) {this.weight = weight;}
?
}

他們都有同樣的功能

上一段講過了，作為一個Animal，他們都知道自己最多能吃多少，而且他們接受喂食，那么他們應該有一個共通的喂食介面，而且能告訴飼養員他們能吃多少，

寫一個介面Feedable，并寫一個獲得最大喂食量的方法，

public interface Feedable {
    // 獲得計算食量介面
    Integer getMaxFoodAmount();
}

貓咪類可以簡化并實作獲得食量的方法了！

public class Cat extends Animal {
    // name weight 屬性 都在 Animal 里
    public Cat(String name, Integer weight) {
        super.setName(name);
        super.setWeight(weight);
    }
?
    /** 實作計算食量 */
    @Override
    public Integer getMaxFoodAmount() {
        return this.getWeight()/2;
    }
}

同理狗也是這么寫，并且Dog類自己實作他的getMaxFoodAmount方法，可以是return this.getWeight();，狗狗要吃多點，

為什么Animal使用了抽象類，主要我們設計Animal是為了抽象出概念，畢竟我們沒有必要也不應該讓其他專案程式員new出一個Animal類，

其實完全也可以在抽象類中寫入未實作的方法，讓子類實作，但使用介面實作在語意上更清晰，畢竟feedable是一種能力而不是一種已知的物件屬性；

如此一來，feeder就被賦予了一種新能力，只要是個Animal類，我都能喂，

public class Feeder {
    public void feed(List<Animal> animalList) {
        for (Animal animal : animalList) {
            System.out.println("我喂食了" + animal.getName() + " " +                        animal.getMaxFoodAmount() + "斤食物");
        }
    }
}

動物園園長的新需求

現在飼養員Feeder可以很輕松的喂養各類的動物了，每種動物也會”告訴“飼養員他自己該吃多少，但是動物園園長卻提出了新的需求，

園長：我們預算有限啊，你老喂那么多，我們園都要給你喂破產了，

確實，也不能每次都喂一種動物的固定食量，假如它懷孕了呢或者病了，食量也會改變對吧，因此飼養員來控制配食方案比較穩妥，

但是我們上面不就已經寫過一種飼養員控制的版本了，那結果會導致飼養員會越來越肥，

但這次我們換種寫法解決這個問題，

有時候要慎用繼承

首先，我說明一個事情，

由于我們一開始設計一個飼養員可以喂不同種類的動物，但如今每種動物都要分開策劃了，于是我只好繼續寫存在一種”超級飼養員“，他可以喂不同種類的動物，

（主要是因為我設計了Animal這個抽象類，導致了每種繼承它的動物都產生了強耦合，所以有時候還是得慎用繼承啊！）

飼養員的新思路

既然到飼養員自己決定了，那么飼養員應該先寫下他對每種不同動物的不同喂食策略書（最好還要寫一份默認策略），

每種策略都是一個喂食策略，都需要有一個獲取食量方法，這點我們使用介面特性，完全契合我們的策略概念，

先定義策略介面，通過設計傳入泛型，讓介面實作中可以操作T類物件，更靈活

public interface FeedStrategy<T> {
    Integer getFoodAmount(T a);
}

然后定義默認策略和各種動物的策略

public class DefaultFeedStrategy implements FeedStrategy<Animal> {
    @Override
    public Integer getFoodAmount(Animal animal) {
        return animal.getWeight()/2;
    }
}

貓貓狗狗策略

public class CatFeedStrategy implements FeedStrategy<Cat> {
?
    @Override
    public Integer getFoodAmount(Cat a) {
        return 1;
    }
}
?
public class DogFeedStrategy implements FeedStrategy<Dog> {
?
    @Override
    public Integer getFoodAmount(Dog a) {
        return 2;
    }
}

為了更好的區分每種Animal的類別，以便讓程式自動選擇策略，我們加入了一個動物列舉類，并在每種動物初始化時也初始化他們的型別

public enum AnimalEnum {
    CAT("cat","貓咪", new CatFeedStrategy()),
    DOG("dog","狗狗", new DogFeedStrategy()),
    BIRD("bird","鳥兒", new DefaultFeedStrategy()),
    TURTLE("turtle","烏龜", new DefaultFeedStrategy());
    String type;
    String name;
    // 把策略也放進去作為列舉元素的內容，方面后面處理
    FeedStrategy feedStrategy;
?
    AnimalEnum(String type, String name, FeedStrategy feedStrategy) {
        this.type = type;
        this.name = name;
        this.feedStrategy = feedStrategy;
    }
}

在創建貓貓狗狗時，初始化他們的類別

public class Cat extends Animal {
    public Cat(String name, Integer weight) {
        super.setName(name);
        super.setWeight(weight);
        // 初始化type -- 列舉類
        super.setType(AnimalEnum.CAT);
    }
?
    /** 實作計算食量 */
    @Override
    public Integer getMaxFoodAmount() {
        return this.getWeight()/2;
    }
}

策略定義好了，我們現在來給我們的飼養員升級一下

飼養員也采取了泛型寫法，原因是我們建議其他使用者指定飼養動物種類，如果他非要使用Feeder<Animal> 我們也有應對方法

public class Feeder<T extends Animal> {
    //主要喂食方法
    // 輸出：我喂食了YY: XXX（a斤），b斤食物
    public void feed(Animal animal, FeedStrategy f) {
        if (f == null) {
            f = new DefaultFeedStrategy();
        }
        StringBuilder sb = new StringBuilder();
        sb.append("我喂食了").append(animal.getType().name).append(": ").append(animal.getName()).append("（").append(animal.getWeight()).append("斤），").append(f.getFoodAmount(animal)).append("斤食物");
        System.out.println(sb.toString());
    }
?
    // 指定策略
    public void feed(List<T> animals, FeedStrategy f) {
        for (T animal: animals) {
            feed(animal, f);
        }
    }
?
    // 根據動物型別自動選擇策略
    public void feed(List<T> animals) {
        // 使用stream流來給傳入的animals按type分組，為什么要這樣做，是因為防止有人創建new feeder<Animal>并傳入 List<Animal>
        // 這里屬于”設計缺陷“，才這樣處理
        Map<AnimalEnum, List<T>> animalMap = animals.stream().collect(Collectors.groupingBy(a -> a.getType()));
        animalMap.entrySet().stream().forEach(es -> feed(es.getValue(), es.getKey().feedStrategy));
        // 上面一句和下面一段for代碼塊的執行邏輯是一樣的
        //for (Map.Entry<AnimalEnum, List<T>> a : animalMap.entrySet()) {
        //    feed(a.getValue(), a.getKey().feedStrategy);
        //}
    }
}

大功告成，現在的飼養員已經有了一本AnimalEnum喂養專業書，告訴他怎么喂任何一種寵物，

還有一些要注意的地方

飼養指揮部 -- StrategyContext 策略背景關系

往往在實際開發中，會存在一個策略背景關系Context，服務端在里面分析客戶端行為，最終決定執行策略，

而在上文的例子中，沒有這樣的設計，原因是我們用AnimalEnum列舉類的特性代替了他，在執行策略越來越復雜以后，設計一個context能更有效清晰的解決策略選擇問題，

策略真的需要那么多實體嗎 -- lambda 和策略單例

策略單例

一開始我寫的時候，是通過下面的方式寫的，你們品品

switch (animal.getType()) {
                case CAT:
                    f = new CatFeedStrategy();
                    break;
                case DOG:
                    f = new DogFeedStrategy();
                    break;
                case BIRD:
                    f = new DefaultFeedStrategy();
                    break;
                case TURTLE:
                    f = new DefaultFeedStrategy();
                    break;
                default:
                    f = new DefaultFeedStrategy();
}

又是GC被迫營業的一整天，new 這么多策略出來，是完全沒有意義的，于是我想到了上一篇單例模式文章里的最后一個列舉單例，

于是我想到了上一篇單例模式文章里的最后一個列舉單例，

單例模式：https://www.cnblogs.com/roy7sang/p/13585578.html

剛好我又使用了列舉，既然每個列舉元素都是單例的，那么它的屬性應該也是單例的（這個我還沒有驗證，我大概率估計是），

舉這個例子是希望提醒使用者，不要瘋狂new 出策略來使用，應該想辦法使用單例策略來解決，

lambda運算式

另外這種介面實作方式的策略，也可以使用lambda運算式來實作介面，比如

feeder.feed(animalList, animal -> animal.getWeight()/2);

不用你再去寫個策略類

策略模式優缺點

優點

最大的優點當然是靈活，面對不同的需求和情況，做出不同的策略回應
提升代碼可讀性，加強了可拓展性

缺點

當策略類越來越多，需要創建的策略類也會變多
策略類往往都是對外暴露的

轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/1063.html

標籤：設計模式

上一篇：行為型模式之狀態模式

下一篇：設計模式-享元模式

詳解JAVA面向物件的設計模式 （二）、策略模式