介绍

策略模式是一个非常简单且常用的设计模式，策略模式最常见的作用就是解决代码中冗长的 if-else 或 switch 分支判断语句。
本文后半部分应该会让熟悉策略模式的同学也会有一些收获。本文重点在于笔者阅读 Flink 源码过程中发现了一个设计比较巧妙的点，可以对策略模式进行优化，所以特意写篇文章总结输出一下。
本文主要讲述：

• 什么场景需要使用策略模式，即：策略模式的作用，策略模式解决了什么问题
• 策略模式的定义和使用
• 策略工厂类中，如果每次都要返回新的策略对象，怎么优化 if-else 分支判断逻辑？

什么场景需要使用策略模式？

// 根据 type 的不同，执行不同分支的代码逻辑，
private void process(String type){
  if(type == "A"){
    // 执行一大堆 A 类型的代码逻辑

  } else if (type == "B") {
    // 执行一大堆 B 类型的代码逻辑

  } else if (type == "C") {
    // 执行一大堆 C 类型的代码逻辑

  } else {
    // 上述都没有匹配成功，执行默认的代码逻辑，
    // 或者抛出异常打印错误日志等
  }
}

策略模式的定义和使用

策略模式的定义

策略模式，英文全称是 Strategy Design Pattern。在 GoF 的《设计模式》一书中，它是这样定义的：
Define a family of algorithms, encapsulate each one, and make them interchangeable. Strategy lets the algorithm vary independently from clients that use it.
翻译成中文就是：定义一组算法类，将每个算法分别封装起来，让它们可以互相替换。策略模式可以使算法的变化独立于使用它们的客户端（这里的客户端代指使用算法的代码）。

经上述分析，笔者认为策略模式可以达到这样的效果：假设 A 类调用 B 类，那么可以认为 A 类是 B 类的客户端，当 B 类增加了一些策略时，客户端 A 类不用进行任何的代码改动即可使用新策略。
策略模式的使用包含三部分：策略的定义、创建和使用。

策略的定义

策略类的定义比较简单，包含一个策略接口和一组实现这个接口的策略类。所有的策略类都实现相同的接口，所以，客户端代码基于接口而非实现编程，可以灵活地替换不同的策略。

public interface Strategy {
  void algorithmInterface();
}

public class ConcreteStrategyA implements Strategy {
  @Override
  public void  algorithmInterface() {
    //具体的算法...
  }
}

public class ConcreteStrategyB implements Strategy {
  @Override
  public void  algorithmInterface() {
    //具体的算法...
  }
}

如上述代码所示，定义了一个策略接口 Strategy，具体的策略实现类都实现 Strategy 接口，并重写 algorithmInterface 方法，最后客户端根据不同的策略即可调用不同实现类的 algorithmInterface 方法。

策略的创建

可以将创建策略的代码逻辑抽象到工厂类中，提前在工厂类创建好所有策略类，缓存在 Map 中。Map 的 key 为策略类型，value 为具体的策略实现类。当需要使用策略时根据 type 去 Map 中 get 即可获取到相应的策略实现类。

public class StrategyFactory {
  // Map 的 key 为策略类型，value 为具体的策略实现类
  private static final Map<String, Strategy> strategies = new HashMap<>();

  // 提前创建好所有策略类，缓存到 Map 中
  static {
    strategies.put("A", new ConcreteStrategyA());
    strategies.put("B", new ConcreteStrategyB());
  }

  // 需要使用策略时根据 type 去 Map 中 get 即可获取到相应的策略实现类
  public static Strategy getStrategy(String type) {
    if (type == null || type.isEmpty()) {
      throw new IllegalArgumentException("type should not be empty.");
    }
    return strategies.get(type);
  }
}

这里重点在于使用”查表法”代替了大量的分支判断，即每次根据 type 去 Map 中获取，省略了大量的 if-else。

策略的使用

具体使用 A、B、C 何种策略，在具体的场景，可以会根据系统的配置来选择。可以从配置文件中读取出配置，然后传递给策略工厂类 StrategyFactory 的 getStrategy 方法即可获取到相应的策略类。最后调用策略类的 algorithmInterface 方法去执行代码逻辑。
代码如下所示，省略了从配置文件中读取配置的流程。

// 根据 type 的不同，执行不同分支的代码逻辑，
private void process(String type){
 Strategy strategy = StrategyFactory.getStrategy(type);
  // 调用策略类的 algorithmInterface 方法去执行代码逻辑
  strategy.algorithmInterface();
}

当前设计是否容易扩展性

最原始的 process 方法中，首先会判断各种 type，然后执行不同类型的代码逻辑。如果需要扩展新的 D、E、F 类型，需要大量修改 process 方法。

优化后，如果需要扩展新的 D、E、F 类型，流程如下：

• 定义相应的 D、E、F 类型的策略实现类
• 提前在策略工厂类 StrategyFactory 中创建相应的策略实现类，并添加到 Map 中
• 客户端代码不用进行任何改动，即：process 方法不需要进行改动

优化后的代码相对来说职责更加单一，且对调用方非常友好。调用方代码不需要任何改动即可使用新的策略。要做的可能就是在配置文件中配置新的策略即可。

到这里，策略模式的基本知识就讲完了。

有状态的策略类不能提前创建

在策略类的创建部分，在类初始化时，将所有的策略类提前创建好，存放在 Map 中。当需要使用策略时根据 type 去 Map 中 get 即可获取到相应的策略实现类。

假设策略类是有状态的，每次获取策略对象时，都要求创建新的策略类。此时，就不能使用 Map 缓存的方式来优化代码结构了。可以使用如下方式实现策略工厂类：

public class StrategyFactory {
  public static Strategy getStrategy(String type) {
    if (type == null || type.isEmpty()) {
      throw new IllegalArgumentException("type should not be empty.");
    }

    if (type.equals("A")) {
      return new ConcreteStrategyA();
    } else if (type.equals("B")) {
      return new ConcreteStrategyB();
    }

    return null;
  }
}

上述代码又退化回了 if-else 嵌套，当然也可以优化为 switch-case 的设计。
在策略工厂类中，如果每次都要返回新的策略对象，我们还是需要在工厂类中编写 if-else 分支判断逻辑，那这个问题该如何解决呢？
笔者看到文末大家的回答，点赞数最高的评论是：仍然可以用查表法，只不过存储的不再是实例，而是class，使用时获取对应的class，再通过反射创建实例。
反射在这里应该是可以实现，但是笔者感觉不是非常灵活，假设策略实现类需要在这里调用一些有参构造器，且不同的策略类的有参构造器需要传入的参数不同，那么反射实现起来不是非常灵活。
例如 ConcreteStrategyA 的构造器需要传入 age，ConcreteStrategyB 的构造器需要传入 date。对于这样的 case，反射不太好实现，如果实现出来，也是一对 if-else 分支判断。
文末也没有其他令笔者眼前一亮的回答，反倒是笔者在阅读 Flink 源码的过程中，发现了一个笔者感觉比较优秀的解决方案;

策略优化

首先分析一个问题来源：

• 对于无状态的策略类，将所有的策略类提前创建好，存放在 Map 中。当需要使用策略时根据 type 去 Map 中 get 即可获取到相应的策略实现类。
• 对于有状态的策略类，不能提前创建所有的策略类，所以没办法提前创建好将其存放在 Map 中

换种思路：

• 给每个具体的策略类创建相应的策略类工厂。例如 ConcreteStrategyA 的工厂为 StrategyFactoryA， ConcreteStrategyB 的工厂为 StrategyFactoryB。
• 虽然没办法提前创建好策略类放到 Map 中，但是可以将策略类的工厂类提前创建好放到 Map 中。根据传入的 type 就可以从 Map 中获取相应策略类的工厂类，然后执行工厂类的 create 方法即可创建出相应的策略类。

根据上述思路，实现相应代码。
首先定义策略工厂接口，并分别实现策略 A 和策略 B 的工厂类：

// 策略工厂接口
public interface StrategyFactory {
  Strategy create();
}

// 策略 A 的工厂类，用于创建策略 A
public class StrategyFactoryA implements StrategyFactory{
    @Override
    public Strategy create() {
        return new ConcreteStrategyA();
    }
}

// 策略 B 的工厂类，用于创建策略 B
public class StrategyFactoryB implements StrategyFactory{
    @Override
    public Strategy create() {
        return new ConcreteStrategyB();
    }
}

对外开放的工厂实现如下：

public class Factory {

    // Map 的 key 为策略类型，value 为 策略的工厂类
    private static final Map<String, StrategyFactory> 
      STRATEGY_FACTORIES = new HashMap<>();

    static {
       // 将各种实现类的工厂提前创建好放到 Map 中
        STRATEGY_FACTORIES.put("A", new StrategyFactoryA());
        STRATEGY_FACTORIES.put("B", new StrategyFactoryB());
    }

    public static Strategy getStrategy(String type) {
        if (type == null || type.isEmpty()) {
            throw new IllegalArgumentException("type should not be empty.");
        }
        // 根据 type 获取对应的策略工厂
        StrategyFactory strategyFactory = STRATEGY_FACTORIES.get(type);
       // 调用具体工厂类的 create 方法即可创建出相应的策略类
        return strategyFactory.create();
    }
}

Factory 类中定义了 Map，Map 的 key 为策略类型，value 为 策略的工厂类。Factory 类初始化时，将各种实现类的工厂提前创> 建好放到 Map 中。

Factory 类的静态方法 getStrategy 用于根据 type 创建相应的策略类，getStrategy 方法根据 type 从 Map 中获取 type 对应的策略类的工厂，调用具体工厂类的 create 方法即可创建出相应的策略类。

当策略类的构造方法比较复杂也没关系，封装在策略类相应的工厂中即可。

旧方案对于每次要创建新策略类的场景，要搞一堆 if-else 分支判断，上述流程使用 Map 优化了 if-else 分支判断逻辑。但带来了一个新的问题，即：创建出了很多类，相比之前的实现来讲，多了 StrategyFactoryA 和 StrategyFactoryB 类。

为了代码的简洁，可以利用 Java8 的 lambda 表达式将 StrategyFactoryA 和 StrategyFactoryB 类优化掉。截取上述部分代码实现：

// 策略工厂接口
public interface StrategyFactory {
  Strategy create();
}

// 策略 A 的工厂类，用于创建策略 A
public class StrategyFactoryA implements StrategyFactory{
    @Override
    public Strategy create() {
        return new ConcreteStrategyA();
    }
}

Map<String, StrategyFactory> STRATEGY_FACTORIES = new HashMap<>();
// 将各种实现类的工厂提前创建好放到 Map 中
STRATEGY_FACTORIES.put("A", new StrategyFactoryA());

上述代码使用 lambda 优化后：

// 策略工厂接口
public interface StrategyFactory {
  Strategy create();
}

Map<String, StrategyFactory> STRATEGY_FACTORIES = new HashMap<>();
// 将各种实现类的工厂提前创建好放到 Map 中
STRATEGY_FACTORIES.put("A", () -> new ConcreteStrategyA());

关于 lambda 这里就不多解释了。lambda 表达式还能优化为 Java8 的方法引用，代码如下所示：

STRATEGY_FACTORIES.put(“A”, ConcreteStrategyA::new);

最后

把上述整个代码的最终版贴在这里：

// 策略工厂接口
public interface StrategyFactory {
  Strategy create();
}

public class Factory {

    // Map 的 key 为策略类型，value 为 策略的工厂类
    private static final Map<String, StrategyFactory> 
      STRATEGY_FACTORIES = new HashMap<>();

    static {
       // 将各种实现类的工厂提前创建好放到 Map 中
        STRATEGY_FACTORIES.put("A", ConcreteStrategyA::new);
        STRATEGY_FACTORIES.put("B", ConcreteStrategyB::new);
    }

    public static Strategy getStrategy(String type) {
        if (type == null || type.isEmpty()) {
            throw new IllegalArgumentException("type should not be empty.");
        }
        // 根据 type 获取对应的策略工厂
        StrategyFactory strategyFactory = STRATEGY_FACTORIES.get(type);
       // 调用具体工厂类的 create 方法即可创建出相应的策略类
        return strategyFactory.create();
    }
}

代码量相比之前的策略类可以共享的代码设计来讲，只是增加了一个 StrategyFactory 接口的设计，所以整体代码也是非常简洁的。
原文链接：https://guosmilesmile.github.io/2020/07/05/Flink%E4%B8%AD%E5%A6%82%E4%BD%95%E4%BD%BF%E7%94%A8%E7%AD%96%E7%95%A5%E6%A8%A1%E5%BC%8F/