死磕设计模式---策略模式

后端程序员Aska
7,516 阅读15分钟

死磕设计模式---策略模式

日常 Coding 过程中，设计模式四板斧：模版、构建者、责任链、策略，今天来说下第四板斧

策略设计模式。

策略模式还是比较简单并且使用较多的，平常我们多运用策略模式用来消除 if-else、switch 等多重判断的代码，消除 if-else、switch 多重判断 可以有效应对代码的复杂性。

如果分支判断会不断变化（增、删、改），那么可以使用别的技巧让其满足开闭原则，提高代码的扩展性 （策略模式场景主要负责解耦，开闭原则需要额外支持）。

策略模式

什么是策略模式

策略模式在 GoF 的《设计模式》一书中，是这样定义的：

Define a family of algorithms, encapsulate each one, and make them interchangeable. Strategy lets the algorithm vary independently from clients that use it.

定义一组算法类，将每个算法分别封装起来，让它们可以互相替换。策略模式使这些算法在客户端调用它们的时候能够互不影响地变化，客户端代指使用算法的代码。

看到上面的介绍可能不太明白策略模式具体为何物，这里会从最基本的代码说起，一步一步彻底掌握此模式。下述代码可能大家都能联想出对应的业务，根据对应的优惠类型，对价格作出相应的优惠。

image.png

这段代码是能够满足项目中业务需求的，而且很多已上线生产环境的代码也有这类代码。但是，这一段代码存在存在两个弊端：

  1. 代码的复杂性，正常业务代码逻辑肯定会比这个代码块复杂很多，这也就 导致了 if-else 的分支以及代码数量过多。这种方式可以通过将代码拆分成独立函数或者拆分成类来解决。
  2. 开闭原则，价格优惠肯定会 随着不同的时期作出不同的改变，或许新增、删除或修改。如果在一个函数中修改无疑是件恐怖的事情，想想可能多个开发者分别进行开发，杂乱无章的注释，混乱的代码逻辑等情况十有八九会发生。

如何运用策略模式优化上述代码，使程序设计看着简约、可扩展等特性。

  1. 简化代码的复杂性，将不同的优惠类型定义为不同的策略算法实现类。
  2. 保证开闭原则，增加程序的健壮性以及可扩展性。

策略模式示例

将上述代码块改造为策略设计模式，大致需要三个步骤。

  1. 定义抽象策略接口，因为业务使用接口而不是具体的实现类的话，便可以灵活的替换不同的策略；
  2. 定义具体策略实现类，实现自抽象策略接口，其内部封装具体的业务实现；
  3. 定义策略工厂，封装创建策略实现（算法），对客户端屏蔽具体的创建细节。

image.png

目前把抽象策略接口、具体的策略实现类以及策略工厂都已经创建了，现在可以看一下客户端需要如何调用，又是如何对客户端屏蔽具体实现细节的。

image.png

根据代码块图片得知，具体策略类是从策略工厂中获取，确实是取消了 if-else 设计，在工厂中使用 Map 存储策略实现。获取到策略类后执行具体的优惠策略方法就可以获取优惠后的金额。

通过分析大家得知，目前这种设计确实将应用代码的复杂性降低了。如果新增一个优惠策略，只需要新增一个策略算法实现类即可。但是，添加一个策略算法实现，意味着需要改动策略工厂中的代码，还是不符合开闭原则。

如何完整实现符合开闭原则的策略模式，需要借助 Spring 的帮助，详细案例请继续往下看。

项目中真实的应用场景

最近项目中设计的一个功能用到了策略模式，分为两类角色，笔者负责定义抽象策略接口以及策略工厂，不同的策略算法需要各个业务方去实现，可以联想到上文中的优惠券功能。因为是 Spring 项目，所以都是按照 Spring 的方式进行处理，话不多说，上代码。

image.png

可以看到，比对上面的示例代码，有两处明显的变化：

  1. 抽象策略接口中，新定义了 mark() 接口，此接口用来标示算法的唯一性；
  2. 具体策略实现类，使用 @Component 修饰，将对象本身交由 Spring 进行管理 。

小贴士：为了阅读方便，mark() 返回直接使用字符串替代，读者朋友在返回标示时最好使用枚举定义。

接下来继续查看抽象策略工厂如何改造，才能满足开闭原则。

image.png

和之前责任链模式相同 （TODO 添加链接），都是通过 InitializingBean 接口实现中调用 IOC 容器查找对应策略实现，随后将策略实现 mark() 方法返回值作为 key， 策略实现本身作为 value 添加到 Map 容器中等待客户端的调用。

image.png

这里使用的 SpringBoot 测试类，注入策略工厂 Bean，通过策略工厂选择出具体的策略算法类，继而通过算法获取到优惠后的价格。小插曲：如果不想把策略工厂注入 Spring 也可以，实现方法有很多。

总结下本小节，我们通过和 Spring 结合的方式，通过策略设计模式对文初的代码块进行了两块优化：应对代码的复杂性，让其满足开闭原则。更具体一些呢就是 通过抽象策略算法类减少代码的复杂性，继而通过 Spring 的一些特性同时满足了开闭原则，现在来了新需求只要添加新的策略类即可，健壮易扩展。

源码底层如何耍策略模式

自己用肯定觉得不够，必要时候还得看看设计开源框架源码的大佬们如何在代码中运用策略模式的。

在作者了解中，JDK、Spring、SpringMvc、Mybatis、Dubbo 等等都运用了策略设计模式，这里就以 Mybatis 举例说明。

Mybatis 中 Executor 代表执行器，负责增删改查的具体操作。其中用到了两种设计模式，模版方法以及策略模式。

image.png

  • Executor 代表了抽象策略接口，刚才说到的模版方法模式源自 BaseExecutor。
  • Configuration 代表策略工厂，负责创建具体的策略算法实现类。
  • SimpleExecuto、ReuseExecutor... 表示封装了具体的策略算法实现类。

image.png

上述代码块发生在 Configuration 类中创建执行器 Executor，通过 executorType 判断创建不同的策略算法。

上述代码块并没有彻底消除 if-else，因为 Mybatis 中执行器策略基本是固定的，也就是说它只会有这些 if-else 判断，基本不会新增或修改。如果非要消除 if-else，可以这么搞，这里写一下伪代码。

image.png

这种方式叫做 "查表法" ，通过策略工厂实现消除 if-else 分支。最后，Mybatis 太过详细的设计这里不再赘述，有兴趣的小伙伴可以去把源码下载啃一啃。

到了这里可能有读者看出了问题，策略模式就算消除了 if-else 但是如果添加新的策略类，不还是会违反开闭原则么？

没错，因为 Mybatis 本身没有引入 Spring 依赖，所以没有办法借助 IOC 容器实现开闭原则。Spring 是一种开闭原则解决方式，那还有没有别的解决方式？

解决方式有很多，开闭原则核心就是 对原有代码修改关闭，对新增代码开放。可以通过扫描指定包下的自定义注解亦或者通过 instanceof 判断是否继承自某接口都可以。不过， 项目如果用了 Spring 还是消停的吧。

策略模式理论 总结

文章中图文并茂的方式介绍策略模式，通过价格优惠的场景，进而引用本文的重点：策略设计模式，相信小伙伴看完后都会有一定的收获。

策略模式的本质依然是对代码设计解耦合，通过三类角色贯穿整个策略模式：抽象策略接口、策略工厂以及具体的策略实现类。通过细粒度的策略实现类避免了主体代码量过多，减少了设计中的复杂性。

作者听到过很多小伙伴觉得自己做的都是 CRUD 工作，没有挑战性没意思。其实，我想说的是：业务代码一样牛逼，一样能体现程序员的水平。不一定非要高并发、大数据等场景。颇有一屋不扫何以扫天下的意思。

最后抛出一个问题：出现 if-else 的代码，一定要使用策略模式优化么？

如果 if-else 判断分支不多并且是固定的，后续不会出现新的分支，那我们完全 可以通过抽函数的方式降低程序复杂性；不要想法设法去除 if-else 语句，存在即合理。而且，使用策略模式会导致类增多，没有必要为了少量的判断分支引入策略模式。

参考文章：

  • 《设计模式之美：策略模式》

如何抽象策略模式

1 优惠类型实战

下述代码可能大家都能联想出对应的业务，根据对应的优惠类型，对价格作出相应的优惠。

image.png

这段代码是能够满足项目中业务需求的，而且很多已上线生产环境的代码也有这类代码。但是，这一段代码存在存在两个弊端：

  1. 代码的复杂性，正常业务代码逻辑肯定会比这个代码块复杂很多，这也就 导致了 if-else 的分支以及代码数量过多。这种方式可以通过将代码拆分成独立函数或者拆分成类来解决。
  2. 开闭原则，价格优惠肯定会 随着不同的时期作出不同的改变，或许新增、删除或修改。如果在一个函数中修改无疑是件恐怖的事情，想想可能多个开发者分别进行开发，杂乱无章的注释，混乱的代码逻辑等情况十有八九会发生。

如何运用策略模式优化上述代码，使程序设计看着简约、可扩展等特性

  1. 简化代码的复杂性，将不同的优惠类型定义为不同的策略算法实现类。
  2. 保证开闭原则，增加程序的健壮性以及可扩展性。

将上述代码块改造为策略设计模式，大致需要三个步骤

  1. 定义抽象策略接口，因为业务使用接口而不是具体的实现类的话，便可以灵活的替换不同的策略；
  2. 定义具体策略实现类，实现自抽象策略接口，其内部封装具体的业务实现；
  3. 定义策略工厂，封装创建策略实现（算法），对客户端屏蔽具体的创建细节。

image.png

目前把抽象策略接口、具体的策略实现类以及策略工厂都已经创建了，现在可以看一下客户端需要如何调用，又是如何对客户端屏蔽具体实现细节的。

image.png

根据代码块图片得知，具体策略类是从策略工厂中获取，确实是取消了 if-else 设计，在工厂中使用 Map 存储策略实现。获取到策略类后执行具体的优惠策略方法就可以获取优惠后的金额。

通过分析大家得知，目前这种设计确实将应用代码的复杂性降低了。如果新增一个优惠策略，只需要新增一个策略算法实现类即可。但是，添加一个策略算法实现，意味着需要改动策略工厂中的代码，还是不符合开闭原则。

如何完整实现符合开闭原则的策略模式，需要借助 Spring 的帮助，详细案例请继续往下看。

2策略模式结合 Spring

最近项目中设计的一个功能用到了策略模式，分为两类角色，笔者负责定义抽象策略接口以及策略工厂，不同的策略算法需要各个业务方去实现，可以联想到上文中的优惠券功能。因为是 Spring 项目，所以都是按照 Spring 的方式进行处理

image.png

可以看到，比对上面的示例代码，有两处明显的变化：

  1. 抽象策略接口中，新定义了 mark() 接口，此接口用来标示算法的唯一性；
  2. 具体策略实现类，使用 @Component 修饰，将对象本身交由 Spring 进行管理 。

小贴士：为了阅读方便，mark() 返回直接使用字符串替代，读者朋友在返回标示时最好使用枚举定义。

接下来继续查看抽象策略工厂如何改造，才能满足开闭原则

image.png

通过 InitializingBean 接口实现中调用 IOC 容器查找对应策略实现，随后将策略实现 mark() 方法返回值作为 key， 策略实现本身作为 value 添加到 Map 容器中等待客户端的调用。

image.png

这里使用的 SpringBoot 测试类，注入策略工厂 Bean，通过策略工厂选择出具体的策略算法类，继而通过算法获取到优惠后的价格。

总结下本小节，我们通过和 Spring 结合的方式，通过策略设计模式对文初的代码块进行了两块优化：应对代码的复杂性，让其满足开闭原则。

更具体一些呢就是 通过抽象策略算法类减少代码的复杂性，继而通过 Spring 的一些特性同时满足了开闭原则，现在来了新需求只要添加新的策略类即可，健壮易扩展。

策略模式抽象

可能细心的小伙伴会发现一个问题，当业务使用越来越多的情况下，重复定义 DiscountStrategy 以及 DiscountStrategyFactory 会增加系统冗余代码量。

可以考虑将这两个基础类抽象出来，作为基础组件库中的通用组件，供所有系统下的业务使用，从而避免代码冗余。

定义抽象策略处理接口，添加有返回值和无返回值接口。

package org.opengoofy.congomall.springboot.starter.designpattern.strategy;

/**
 * 策略执行抽象
 */
public interface AbstractExecuteStrategy<REQUEST, RESPONSE> {

    /**
     * 执行策略标识
     */
    String mark();

    /**
     * 执行策略
     *
     * @param requestParam 执行策略入参
     */
    default void execute(REQUEST requestParam) {

    }

    /**
     * 执行策略，带返回值
     *
     * @param requestParam 执行策略入参
     * @return 执行策略后返回值
     */
    default RESPONSE executeResp(REQUEST requestParam) {
        return null;
    }
}

添加策略选择器，通过订阅 Spring 初始化事件执行扫描所有策略模式接口执行器，并根据 mark 方法定义标识添加到 abstractExecuteStrategyMap 容器中。

客户端在实际业务中使用 AbstractStrategyChoose#choose 即可完成策略模式实现。

package org.opengoofy.congomall.springboot.starter.designpattern.strategy;

import org.opengoofy.congomall.springboot.starter.base.ApplicationContextHolder;
import org.opengoofy.congomall.springboot.starter.base.init.ApplicationInitializingEvent;
import org.opengoofy.congomall.springboot.starter.convention.exception.ServiceException;
import org.springframework.context.ApplicationListener;

import java.util.HashMap;
import java.util.Map;
import java.util.Optional;

/**
 * 策略选择器
 */
public class AbstractStrategyChoose implements ApplicationListener<ApplicationInitializingEvent> {

    /**
     * 执行策略集合
     */
    private final Map<String, AbstractExecuteStrategy> abstractExecuteStrategyMap = new HashMap<>();

    /**
     * 根据 mark 查询具体策略
     *
     * @param mark 策略标识
     * @return 实际执行策略
     */
    public AbstractExecuteStrategy choose(String mark) {
        return Optional.ofNullable(abstractExecuteStrategyMap.get(mark)).orElseThrow(() -> new ServiceException(String.format("[%s] 策略未定义", mark)));
    }

    /**
     * 根据 mark 查询具体策略并执行
     *
     * @param mark         策略标识
     * @param requestParam 执行策略入参
     * @param <REQUEST>    执行策略入参范型
     */
    public <REQUEST> void chooseAndExecute(String mark, REQUEST requestParam) {
        AbstractExecuteStrategy executeStrategy = choose(mark);
        executeStrategy.execute(requestParam);
    }

    /**
     * 根据 mark 查询具体策略并执行，带返回结果
     *
     * @param mark         策略标识
     * @param requestParam 执行策略入参
     * @param <REQUEST>    执行策略入参范型
     * @param <RESPONSE>   执行策略出参范型
     * @return
     */
    public <REQUEST, RESPONSE> RESPONSE chooseAndExecuteResp(String mark, REQUEST requestParam) {
        AbstractExecuteStrategy executeStrategy = choose(mark);
        return (RESPONSE) executeStrategy.executeResp(requestParam);
    }

    @Override
    public void onApplicationEvent(ApplicationInitializingEvent event) {
        Map<String, AbstractExecuteStrategy> actual = ApplicationContextHolder.getBeansOfType(AbstractExecuteStrategy.class);
        actual.forEach((beanName, bean) -> {
            AbstractExecuteStrategy beanExist = abstractExecuteStrategyMap.get(bean.mark());
            if (beanExist != null) {
                throw new ServiceException(String.format("[%s] Duplicate execution policy", bean.mark()));
            }
            abstractExecuteStrategyMap.put(bean.mark(), bean);
        });
    }
}

这两个实现已经被放置在基础组件库中，如果业务需要使用策略模式，则无需重新定义。

总结

总的来说，策略模式是一种非常有用的设计模式，它可以帮助我们在运行时动态地选择不同的算法实现，从而提高代码的灵活性、可维护性和可扩展性。

通过将算法实现封装在不同的策略类中，并定义一个策略接口来描述算法，策略模式使得客户端可以独立于算法实现进行编程，同时也可以方便地更换算法实现或者添加新的算法实现。

策略模式的优点包括提高代码的灵活性、可维护性、可扩展性和复用性，同时也可以避免使用大量的条件语句和提高代码的可读性。

需要注意的是，在使用策略模式时需要遵循一些设计原则，例如开闭原则、单一职责原则和依赖倒置原则等，以确保代码的高内聚性和低耦合度。

此外，策略模式适用于需要在运行时动态选择不同算法实现的场景，如果算法实现不需要动态切换或者算法实现较为简单，策略模式可能会显得过于复杂。

因此，在使用策略模式时需要根据具体的需求和场景进行判断和选择。

avatar
文章
阅读
粉丝