详解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教程