设计模式--策略模式

splendor.s

已于 2023-03-25 10:16:02 修改

阅读量546

点赞数 2

分类专栏： # 设计模式 Java技术体系文章标签：策略模式

于 2019-10-23 16:38:51 首次发布

本文链接：https://blog.csdn.net/shylogo/article/details/102703053

版权

Java技术体系同时被 2 个专栏收录

26 篇文章 0 订阅

订阅专栏

设计模式

9 篇文章 0 订阅

订阅专栏

在软件开发中也常常遇到类似的情况，当实现某一个功能存在多种算法或者策略，我们可以根据环境或者条件的不同选择不同的算法或者策略来完成该功能，如数据排序策略有冒泡排序、选择排序、插入排序、二叉树排序等。

如果使用多重条件转移语句（例如万恶的if--else）实现（即硬编码），不但使条件语句变得很复杂，而且增加、删除或更换算法要修改原代码，不易维护，违背开闭原则。如果采用策略模式就能很好解决该问题。

策略模式的定义与特点

策略（Strategy）模式的定义：该模式定义了一系列算法，并将每个算法封装起来，使它们可以相互替换，且算法的变化不会影响使用算法的客户。策略模式属于对象行为模式，它通过对算法进行封装，把使用算法的责任和算法的实现分割开来，并委派给不同的对象对这些算法进行管理。

策略模式的主要优点如下。

多重条件语句不易维护，而使用策略模式可以避免使用多重条件语句。
策略模式提供了一系列的可供重用的算法族，恰当使用继承可以把算法族的公共代码转移到父类里面，从而避免重复的代码。
策略模式可以提供相同行为的不同实现，客户可以根据不同时间或空间要求选择不同的。
策略模式提供了对开闭原则的完美支持，可以在不修改原代码的情况下，灵活增加新算法。
策略模式把算法的使用放到环境类中，而算法的实现移到具体策略类中，实现了二者的分离。

当然也是有缺点的，其主要缺点如下。

客户端必须理解所有策略算法的区别，以便适时选择恰当的算法类。
策略模式造成很多的策略类。

策略模式的结构与实现

1. 模式的结构

策略模式的主要角色如下。

抽象策略（Strategy）类：定义了一个公共接口，各种不同的算法以不同的方式实现这个接口，环境角色使用这个接口调用不同的算法，一般使用接口或抽象类实现。
具体策略（Concrete Strategy）类：实现了抽象策略定义的接口，提供具体的算法实现。
环境（Context）类：持有一个策略类的引用，最终给客户端调用。

其结构图如图所示：

图1 策略模式的结构图

2. 模式的实现

策略模式的实现代码如下：

package strategy;
public class StrategyPattern {

    public static void main(String[] args) {
        Context sc=new Context();
        Strategy ss=new ConcreteStrategyA();
        sc.setStrategy(ss);
        sc.strategyMethod();
        System.out.println("-----------------");
        ss=new ConcreteStrategyB();
        sc.setStrategy(ss);
        sc.strategyMethod();
    }
}
//抽象策略接口
interface Strategy {   
    public void strategyMethod();    //策略方法
}
//具体策略类A
class ConcreteStrategyA implements Strategy {
    public void strategyMethod() {
        System.out.println("具体策略A的策略方法被访问！");
    }
}
//具体策略类B
class ConcreteStrategyB implements Strategy {
  public void strategyMethod() {
      System.out.println("具体策略B的策略方法被访问！");
  }
}
//环境类
class Context {
    private Strategy strategy;
    public Strategy getStrategy() {
        return strategy;
    }
    public void setStrategy(Strategy strategy) {
        this.strategy=strategy;
    }
    public void strategyMethod() {
        strategy.strategyMethod();
    }
}

程序运行结果如下：

具体策略A的策略方法被访问！
-----------------
具体策略B的策略方法被访问！

策略模式的应用实例

1、外卖平台上的某家店铺为了促销，设置了多种会员优惠，其中包含超级会员折扣8折、普通会员折扣9折和普通用户没有折扣三种。

2、希望用户在付款的时候，根据用户的会员等级，就可以知道用户符合哪种折扣策略，进而进行打折，计算出应付金额。

3、随着业务发展，新的需求要求专属会员要在店铺下单金额大于30元的时候才可以享受优惠。

4、接着，又有一个变态的需求，如果用户的超级会员已经到期了，并且到期时间在一周内，那么就对用户的单笔订单按照超级会员进行折扣，并在收银台进行强提醒，引导用户再次开通会员，而且折扣只进行一次。

常规思路采用“恶心”的if--else，而过多的if-else代码和嵌套，会使阅读代码的人很难理解到底是什么意思。其次是可维护性，因为if-else特别多，想要新加一个分支的时候，就会很难添加，极其容易影响到其他的分支。最后如果新业务需要定制的时候，都把自己的if放到整个方法的最前面，以保证自己的逻辑可以正常执行。代码就 “看不得”-->请拿开

其实，if-else是有办法可以消除掉的，其中比较典型的并且使用广泛的就是借助策略模式和工厂模式(前面有介绍)，准确的说是利用这两个设计模式的思想，彻底消灭代码中的if-else。

例如这常规思路伪码：

public BigDecimal calPrice(BigDecimal orderPrice, String buyerType) {

    if (用户是专属会员) {
        if (订单金额大于30元) {
            returen 7折价格;
        }
    }

    if (用户是超级会员) {
        return 8折价格;
    }

    if (用户是普通会员) {
        if(该用户超级会员刚过期并且尚未使用过临时折扣){
            临时折扣使用次数更新();
            returen 8折价格;
        }
        return 9折价格;
    }
    return 原价;
}

以上，就是对于这个需求的一段价格计算逻辑，使用伪代码都这么复杂，如果是真的写代码，那复杂度可想而知。

这样的代码中，有很多if-else，并且还有很多的if-else的嵌套，无论是可读性还是可维护性都非常低。

接下来重头戏：

策略模式

接下来，我们尝试引入策略模式来提升代码的可维护性和可读性。

首先，定义一个接口：

public interface UserPayService {

    /**
     * 计算应付价格
     */
    public BigDecimal quote(BigDecimal orderPrice);
}

接着定义几个策略类：

public class ParticularlyVipPayService implements UserPayService {

    @Override
    public BigDecimal quote(BigDecimal orderPrice) {
         if (消费金额大于30元) {
            return 7折价格;
        }
    }
}

public class SuperVipPayService implements UserPayService {

    @Override
    public BigDecimal quote(BigDecimal orderPrice) {
        return 8折价格;
    }
}

public class VipPayService implements UserPayService {

    @Override
    public BigDecimal quote(BigDecimal orderPrice) {
        if(该用户超级会员刚过期并且尚未使用过临时折扣){
            临时折扣使用次数更新();
            returen 8折价格;
        }
        return 9折价格;
    }
}

引入了策略之后，我们可以按照如下方式进行价格计算：

public class Test {

    public static void main(String[] args) {
        UserPayService strategy = new VipPayService();
        BigDecimal quote = strategy.quote(300);
        System.out.println("普通会员商品的最终价格为：" + quote.doubleValue());

        strategy = new SuperVipPayService();
        quote = strategy.quote(300);
        System.out.println("超级会员商品的最终价格为：" + quote.doubleValue());
    }
}

以上，就是一个例子，可以在代码中new出不同的会员的策略类，然后执行对应的计算价格的方法。

但是，真正在代码中使用，比如在一个web项目中使用，上面这个Demo根本没办法直接用。

首先，在web项目中，上面我们创建出来的这些策略类都是被Spring托管的，我们不会自己去new一个实例出来。

其次，在web项目中，如果真要计算价格，也是要事先知道用户的会员等级，比如从数据库中查出会员等级，然后根据等级获取不同的策略类执行计算价格方法。

那么，web项目中真正的计算价格的话，伪代码应该是这样的：

public BigDecimal calPrice(BigDecimal orderPrice,User user) {

     String vipType = user.getVipType();

     if (vipType == 专属会员) {
        //伪代码：从Spring中获取超级会员的策略对象
        UserPayService strategy = Spring.getBean(ParticularlyVipPayService.class);
        return strategy.quote(orderPrice);
     }

     if (vipType == 超级会员) {
        UserPayService strategy = Spring.getBean(SuperVipPayService.class);
        return strategy.quote(orderPrice);
     }

     if (vipType == 普通会员) {
        UserPayService strategy = Spring.getBean(VipPayService.class);
        return strategy.quote(orderPrice);
     }
     return 原价;
}

通过以上代码，我们发现，代码可维护性和可读性好像是好了一些，但是好像并没有减少if-else啊。

客户端必须知道所有的策略类，并自行决定使用哪一个策略类。这就意味着客户端必须理解这些算法的区别，以便适时选择恰当的算法类。

也就是说，虽然在计算价格的时候没有if-else了，但是选择具体的策略的时候还是不可避免的还是要有一些if-else。

另外，上面的伪代码中，从Spring中获取会员的策略对象我们是伪代码实现的，那么代码到底该如何获取对应的Bean呢？

接下来我们看如何借助Spring和工厂模式，解决上面这些问题。

工厂模式

为了方便我从Spring中获取UserPayService的各个策略类，我们创建一个工厂类：

public class UserPayServiceStrategyFactory {

    private static Map<String,UserPayService> services = new ConcurrentHashMap<String,UserPayService>();

    public  static UserPayService getByUserType(String type){
        return services.get(type);
    }

    public static void register(String userType,UserPayService userPayService){
        Assert.notNull(userType,"userType can't be null");
        services.put(userType,userPayService);
    }
}
这个UserP

这个UserPayServiceStrategyFactory中定义了一个Map，用来保存所有的策略类的实例，并提供一个getByUserType方法，可以根据类型直接获取对应的类的实例。还有一个register方法，这个后面再讲。

有了这个工厂类之后，计算价格的代码即可得到大大的优化：

public BigDecimal calPrice(BigDecimal orderPrice,User user) {

     String vipType = user.getVipType();
     UserPayService strategy = UserPayServiceStrategyFactory.getByUserType(vipType);
     return strategy.quote(orderPrice);
}

以上代码中，不再需要if-else了，拿到用户的vip类型之后，直接通过工厂的getByUserType方法直接调用就可以了。

通过策略+工厂，我们的代码很大程度的优化了，大大提升了可读性和可维护性。

但是，上面还遗留了一个问题，那就是UserPayServiceStrategyFactory中用来保存所有的策略类的实例的Map是如何被初始化的？各个策略的实例对象如何塞进去的呢？

Spring Bean的注册

前面定义的UserPayServiceStrategyFactory中提供了的register方法，他就是用来注册策略服务的。

接下来，我们就想办法调用register方法，把Spring通过IOC创建出来的Bean注册进去就行了。

这种需求，可以借用Spring种提供的InitializingBean接口，这个接口为Bean提供了属性初始化后的处理方法，它只包括afterPropertiesSet方法，凡是继承该接口的类，在bean的属性初始化后都会执行该方法。

那么，我们将前面的各个策略类稍作改造即可：

@Service
public class ParticularlyVipPayService implements UserPayService,InitializingBean {

    @Override
    public BigDecimal quote(BigDecimal orderPrice) {
         if (消费金额大于30元) {
            return 7折价格;
        }
    }

    @Override
    public void afterPropertiesSet() throws Exception {
        UserPayServiceStrategyFactory.register("ParticularlyVip",this);
    }
}

@Service
public class SuperVipPayService implements UserPayService ,InitializingBean{

    @Override
    public BigDecimal quote(BigDecimal orderPrice) {
        return 8折价格;
    }

    @Override
    public void afterPropertiesSet() throws Exception {
        UserPayServiceStrategyFactory.register("SuperVip",this);
    }
}

@Service  
public class VipPayService implements UserPayService,InitializingBean {

    @Override
    public BigDecimal quote(BigDecimal orderPrice) {
        if(该用户超级会员刚过期并且尚未使用过临时折扣){
            临时折扣使用次数更新();
            returen 8折价格;
        }
        return 9折价格;
    }

    @Override
    public void afterPropertiesSet() throws Exception {
        UserPayServiceStrategyFactory.register("Vip",this);
    }
}

只需要每一个策略服务的实现类都实现InitializingBean接口，并实现其afterPropertiesSet方法，在这个方法中调用UserPayServiceStrategyFactory.register即可。

这样，在Spring初始化的时候，当创建VipPayService、SuperVipPayService和ParticularlyVipPayService的时候，会在Bean的属性初始化之后，把这个Bean注册到UserPayServiceStrategyFactory中。

以上代码，其实还是有一些重复代码的，这里面还可以引入模板方法模式进一步精简，这里就不展开了。

还有就是，UserPayServiceStrategyFactory.register调用的时候，第一个参数需要传一个字符串，这里的话其实也可以优化掉。比如使用枚举，或者在每个策略类中自定义一个getUserType方法，各自实现即可。

总结

通过策略模式、工厂模式以及Spring的InitializingBean，提升了代码的可读性以及可维护性，彻底消灭了一坨if-else。

文中的这种做法，大家可以立刻尝试起来，这种实践，是我们日常开发中经常用到的，而且还有很多衍生的用法，也都非常好用。文中使用的并不是严格意义上面的策略模式和工厂模式。

首先，策略模式中重要的Context角色在这里面是没有的，没有Context，也就没有用到组合的方式，而是使用工厂代替了。

另外，这里面的UserPayServiceStrategyFactory其实只是维护了一个Map，并提供了register和get方法而已，而工厂模式其实是帮忙创建对象的，这里并没有用到。

最后，对于设计模式的学习，重要的是学习其思想，而不是代码实现！！！

splendor.s

关注

2
点赞
踩
0

收藏

觉得还不错? 一键收藏
2
评论
设计模式--策略模式

在软件开发中也常常遇到类似的情况，当实现某一个功能存在多种算法或者策略，我们可以根据环境或者条件的不同选择不同的算法或者策略来完成该功能，如数据排序策略有冒泡排序、选择排序、插入排序、二叉树排序等。如果使用多重条件转移语句（例如万恶的if--else）实现（即硬编码），不但使条件语句变得很复杂，而且增加、删除或更换算法要修改原代码，不易维护，违背开闭原则。如果采用策略模式就能很好解...
复制链接

扫一扫