设计模式之策略模式

·  阅读 298

「这是我参与11月更文挑战的第23天,活动详情查看:2021最后一次更文挑战

本篇文章是设计模式专题的第二篇文章,我会将遇到的设计模式都一一总结在该专题下,我会把自己对每一种设计模式的感悟写下来,以及在实际工作中我们该如何去灵活应用这些设计模式,欢迎大家关注。本篇文章我们就来讲一讲,最为优雅的策略模式。

策略模式的简单介绍

策略模式就是我们在针对某一个功能有多种实现方式,我们可以根据环境不同或者条件不同,选择不同的实现方式。

策略模式的类图如下:

策略模式类图

解释:Context是上下文,Strategy是策略类的公共接口;ConcreteStrategy是具体策略的实现,可以有N多个,封装了具体的算法或行为,实现Strategy接口。

策略模式的具体实现思路

  • 定义一个上下文对象,可以通过上下文对象获取对应的具体实现类。
  • 定义抽象策略类,定义每个策略或算法必须具有的方法和属性,通常为接口。
  • 定义具体策略类,对抽象策略类的算法提供具体实现。

策略模式的具体实现方案

  • 创建上下文对象

    Context上下文,起承上启下的作用,屏蔽高层模块对策略、算法的直接访问,封装可能存在的变化。

    public class Context {
         
         Strategy strategy;
         
         public Context(Strategy strategy) {
             this.strategy = strategy;
         }
         
         //上下文接口
         public void contextInterface() {
             strategy.algorithmInterface();
         }
    ​
     }
    复制代码
  • 创建抽象策略类

    抽象策略类,是对策略、算法的抽象,通常为接口,定义每个策略或算法必须具有的方法和属性。

    public abstract class Strategy {
         
         //算法方法
         public abstract void algorithmInterface();
     
    }
    复制代码
  • 创建策略类的具体实现

    如果是接口的话需要implements实现接口

    如果一个抽象策略的实现多于四个,就需要考虑使用混合模式来解决策略类膨胀的问题

    public class ConcreteStrategyA extends Strategy {
    ​
        @Override
        public void algorithmInterface() {
            System.out.println("算法A实现");
        }
    ​
    }
    复制代码
    public class ConcreteStrategyB extends Strategy {
    ​
        @Override
        public void algorithmInterface() {
            System.out.println("算法B实现");
        }
    ​
    }
    复制代码

策略模式的优缺点

优点

  • 算法可以自由切换,灵活性强
  • 避免使用多重条件判断(如果不用策略模式我们可能会使用多重条件语句,不利于维护)
  • 扩展性极强,可以无限扩展策略

缺点

  • 策略类数量会增多,每个策略都是一个类,复用的可能性很小
  • 所有的策略类都需要对外暴露

策略模式的适用场景

适用场景:

  1. 多个类只有算法或行为上略有不同
  2. 算法需要自由切换
  3. 需要屏蔽算法规则

举例:

  • 出行方式
  • 促销方式
  • 导出方式
  • 排序方式
  • 其实我们业务中有很多地方可以用策略模式去优化,尤其是多重if...else...里边含有大量的逻辑处理
  • ...

策略模式总结

策略模式是我个人非常喜欢的一种设计模式,我认为这种设计模式能让我们的代码实现起来更加优雅。我非常不喜欢那种用超长的if...else去区分策略,代码可读性非常差,不易调试,策略模式往往能够很好地去改善这种代码,我个人在工作中也非常喜欢使用策略模式。

分类:
后端