详解JAVA面向对象的设计模式（二）、策略模式

策略模式 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);

不用你再去写个策略类

策略模式优缺点

优点

最大的优点当然是灵活，面对不同的需求和情况，做出不同的策略回应
提升代码可读性，加强了可拓展性

缺点

当策略类越来越多，需要创建的策略类也会变多
策略类往往都是对外暴露的

posted @ 2020-09-05 17:55 Rooooy7 阅读(474) 评论(0) 收藏举报

刷新页面返回顶部

Rooooy7

详解JAVA面向对象的设计模式 （二）、策略模式