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

時間  2020-09-14
標籤 詳解 java 面向對象 設計 模式 策略 欄目 Java 简体版
原文   原文鏈接

策略模式 Strategy

介紹

在策略模式（Strategy Pattern）中，一個類的行爲或其算法能夠在運行時更改。這種類型的設計模式屬於行爲型模式。html

在策略模式中，咱們建立表示各類策略的對象和一個行爲隨着策略對象改變而改變的 context 對象。策略對象改變 context 對象的執行算法。git

Intent

定義一系列算法，封裝每一個算法，並使它們能夠互換。程序員

策略模式可讓算法獨立於使用它的客戶端。github

前言

本篇會以一個飼養員的飼養工做爲例，一步步碼到使用策略模式解決實際問題。算法

首先咱們看看遇到相似以下的問題時，該怎麼辦。設計模式

  1. 有多種類別的多個寵物須要餵食。app

  2. 只有一我的（對象）知道不一樣寵物應該根據它的體重喂多少食物。ide

 本篇文章部分參考 ：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.mdui

 你能夠在這篇文章裏找到最簡潔的策略模式實現this

一直膨脹的飼養員

最直接的實現方式，就是建立一個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 這麼多策略出來，是徹底沒有意義的。因而我想到了上一篇單例模式文章裏的最後一個枚舉單例。

因而我想到了上一篇單例模式文章裏的最後一個枚舉單例。

單例模式：http://www.javashuo.com/article/p-cunxhbwg-mx.html

恰好我又使用了枚舉，既然每一個枚舉元素都是單例的，那麼它的屬性應該也是單例的（這個我尚未驗證，我大機率估計是）。

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

lambda表達式

另外這種接口實現方式的策略。也可使用lambda表達式來實現接口。好比 

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

不用你再去寫個策略類

策略模式優缺點

優勢

  • 最大的優勢固然是靈活，面對不一樣的需求和狀況，作出不一樣的策略迴應

  • 提高代碼可讀性，增強了可拓展性

缺點

  • 當策略類愈來愈多，須要建立的策略類也會變多

  • 策略類每每都是對外暴露的

相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程