设计模式最佳实践探索—策略模式

策略模式属于对象的行为模式，其用意是针对一组可替换的算法，将每一个算法封装到具有共同接口的独立的类中，使得算法可以在不影响到客户端（算法的调用方）的情况下发生变化，使用策略模式可以将算法的定义与使用隔离开来，保证类的单一职责原则，使得程序整体符合开闭原则。

以手淘中商详页的店铺卡片为例，店铺卡片主要包含店铺名称、店铺logo、店铺类型以及店铺等级等信息，其中不同店铺类型的店铺等级计算逻辑是不同的，为了获取店铺等级，可以采用如下所示代码：

 if (Objects.equals("淘宝", shopType)) {   // 淘宝店铺等级计算逻辑   // return 店铺等级； } else if (Objects.equals("天猫", shopType)) {   // 天猫店铺等级计算逻辑   // return 店铺等级 } else if (Objects.equals("淘特", shopType)) {   // 淘特店铺等级计算逻辑   // return 店铺等级 } else {   //  ... }

这样一来，程序便具有了良好的可扩展性与易修改性，若想增加一种新的店铺等级计算逻辑，则可将其对应的等级计算逻辑单独封装成ShopRankHandler接口的实现类即可，同样的，若想对其中一种策略的实现进行更改，在相应的实现类中进行更改即可，而不用侵入原有代码中去开发。

• 效果

至此，当我们需要新增策略类时，需要做的改动如下：

1. 新建策略类并实现策略接口

2. 增加枚举类型

3. 工厂类中初始化时增加新的策略类

相比上一种方式，策略类与客户端进行解耦，无需更改客户端的代码。

• 优点

将客户端与策略类进行解耦，客户端只面向策略接口进行编程，对具体策略类的变化（更改、增删）完全无感知，符合开闭原则。

• 缺点

需要引入额外的工厂类，使系统结构变得复杂。

当新加入策略类时，工厂类中初始化策略的部分仍然需要改动。

▐  第二次迭代（利用Spring框架初始化策略beans）

在枚举+简单工厂实现的方式中，利用简单工厂将客户端与具体的策略类实现进行了解耦，但工厂类中初始化策略beans的部分仍然与具体策略类存在耦合，为了进一步解耦，我们可以利用Spring框架中的InitializingBean接口与ApplicationContextAware接口来实现策略beans的自动装配。InitializingBean接口中的afterPropertiesSet()方法在类的实例化过程当中执行，也就是说，当客户端完成注入ShopRankHandlerFactory工厂类实例的时候，afterPropertiesSet()也已经执行完成。因此我们可以通过重写afterPropertiesSet()方法，在其中利用getBeansOfType()方法来获取到策略接口的所有实现类，并存于Map容器之中，达到工厂类与具体的策略类解耦的目的。相比于上一种实现方式，需要改动的代码如下：

1. 店铺等级计算接口

   public interface ShopRankHandler {    /**    * 获取店铺类型的方法，接口的实现类需要根据各自的枚举类型来实现，后面就不贴出实现类的代码    * @return 店铺等级    */    String getType();    /**    * 计算店铺等级    * @return 店铺等级    */    String calculate();}

2. 策略工厂类

   @Componentpublic class ShopRankHandlerFactory implements InitializingBean, ApplicationContextAware {
       private ApplicationContext applicationContext;    /**     * 策略实例容器     */    private Map<String, ShopRankHandler> GET_SHOP_RANK_STRATEGY_MAP;
       /**     * 根据店铺类型获取对应的获取店铺卡片实现类     *     * @param shopType 店铺类型     * @return 店铺类型对应的获取店铺卡片实现类     */    public ShopRankHandler getStrategy(String shopType) {        return GET_SHOP_RANK_STRATEGY_MAP.get(shopType);    }
       @Override    public void afterPropertiesSet() {        Map<String, ShopRankHandler> beansOfType = applicationContext.getBeansOfType(ShopRankHandler.class);
           GET_SHOP_RANK_STRATEGY_MAP = Optional.ofNullable(beansOfType)                            .map(beansOfTypeMap -> beansOfTypeMap.values().stream()                                    .filter(shopRankHandle -> StringUtils.isNotEmpty(shopRankHandle.getType()))                                    .collect(Collectors.toMap(ShopRankHandler::getType, Function.identity())))                            .orElse(new HashMap<>(8));    }
       @Override    public void setApplicationContext(ApplicationContext applicationContext) throws BeansException {        this.applicationContext = applicationContext;    }
   }

• 效果

至此，当我们需要新增策略类时，需要做的改动如下：

1. 新建策略类并实现策略接口

2. 增加枚举类型

相比于上一种方式，可以省略工厂类在初始化策略beans时要增加新的策略类这一步骤。

• 优点

借助Spring框架完成策略beans的自动装配，使得策略工厂类与具体的策略类进一步解耦。

• 缺点

需要借助Spring框架来完成，不过在Spring框架应用如此广泛的今天，这个缺点可以忽略不计。

▐  最终迭代（利用泛型进一步提高策略工厂复用性）

经过上面两次迭代以后，策略模式的实现已经变得非常方便，当需求发生改变的时候，我们再也不用手忙脚乱了，只需要关注新增或者变化的策略类就好，而不用侵入原有逻辑去开发。但是还有没有改进的空间呢？

设想一下有一个新业务同样需要策略模式来实现，如果为其重新写一个策略工厂类，整个策略工厂类中除了新的策略接口外，其他代码均与之前的策略工厂相同，出现了大量重复代码，这是我们所不能忍受的。为了最大程度避免重复代码的出现，我们可以使用泛型将策略工厂类中的策略接口参数化，使其变得更灵活，从而提高其的复用性。

理论存在，实践开始！代码示意如下：

1. 定义泛型接口

   public interface GenericInterface<E> {     E getType();}

2. 定义策略接口继承泛型接口

   public interface StrategyInterfaceA extends GenericInterface<String>{
       String handle();}public interface StrategyInterfaceB extends GenericInterface<Integer>{
       String handle();}public interface StrategyInterfaceC extends GenericInterface<Long>{
       String handle();}

3. 实现泛型策略工厂

   public class HandlerFactory<E, T extends GenericInterface<E>> implements InitializingBean, ApplicationContextAware {    private ApplicationContext applicationContext;    /**     * 泛型策略接口类型     */    private Class<T> strategyInterfaceType;
       /**     * java泛型只存在于编译期，无法通过例如T.class的方式在运行时获取其类信息     * 因此利用构造函数传入具体的策略类型class对象为getBeansOfType()方法     * 提供参数     *     * @param strategyInterfaceType 要传入的策略接口类型     */    public HandlerFactory(Class<T> strategyInterfaceType) {        this.strategyInterfaceType = strategyInterfaceType;    }    /**     * 策略实例容器     */    private Map<E, T> GET_SHOP_RANK_STRATEGY_MAP;    /**     * 根据不同参数类型获取对应的接口实现类     *     * @param type 参数类型     * @return 参数类型对应的接口实现类     */    public T getStrategy(E type) {        return GET_SHOP_RANK_STRATEGY_MAP.get(type);    }
       @Override    public void afterPropertiesSet() {        Map<String, T> beansOfType = applicationContext.getBeansOfType(strategyInterfaceType);        System.out.println(beansOfType);
           GET_SHOP_RANK_STRATEGY_MAP = Optional.ofNullable(beansOfType)                .map(beansOfTypeMap -> beansOfTypeMap.values().stream()                        .filter(strategy -> StringUtils.isNotEmpty(strategy.getType().toString()))                        .collect(Collectors.toMap(strategy -> strategy.getType(), Function.identity())))                .orElse(new HashMap<>(8));        System.out.println(GET_SHOP_RANK_STRATEGY_MAP);    }
       @Override    public void setApplicationContext(ApplicationContext applicationContext) throws BeansException {        this.applicationContext = applicationContext;    }}

4. 有了上述泛型策略工厂类，当我们需要新建一个策略工厂类的时候，只需要利用其构造函数传入相应的策略接口即可。生成StrategyInterfaceA、StrategyInterfaceB与StrategyInterfaceC接口的策略工厂如下：

   public class BeanConfig {    @Bean    public HandlerFactory<String, StrategyInterfaceA> strategyInterfaceAFactory(){        return new HandlerFactory<>(StrategyInterfaceA.class);    }    @Bean    public HandlerFactory<Integer, StrategyInterfaceB> strategyInterfaceBFactory(){        return new HandlerFactory<>(StrategyInterfaceB.class);    }    @Bean    public HandlerFactory<Long, StrategyInterfaceC> strategyInterfaceCFactory(){        return new HandlerFactory<>(StrategyInterfaceC.class);    }  }

• 效果

此时，若想新建一个策略工厂，则只需将策略接口作为参数传入泛型策略工厂即可，无需再写重复的样板代码，策略工厂的复用性大大提高，也大大提高了我们的开发效率。

• 优点

将策略接口类型参数化，策略工厂不受接口类型限制，成为任意接口的策略工厂。

• 缺点

系统的抽象程度、复杂度变高，不利于直观理解。

学习设计模式，关键是学习设计思想，不能简单地生搬硬套，灵活正确地应用设计模式可以让我们在开发中取得事半功倍的效果，但也不能为了使用设计模式而过度设计，要合理平衡设计的复杂度和灵活性。

本文是对策略模式最佳实践的一次探索，不一定是事实上的最佳实践，欢迎大家指正与讨论。

END

开源最终的价值不仅是获客

---

这里有最新开源资讯、软件更新、技术干货等内容

点这里 ↓↓↓ 记得 关注✔ 标星⭐ 哦~