策略模式在AIBOT项目中的实际应用

原文链接https://www.jylt.cc/#/detail?activityIndex=2&id=8d1912358fa1c1d8db1b44e2d1042b70AIBOT 你想我来做AIBOThttps://chat.jylt.top/

定义

策略模式（Strategy Pattern：Define a family of algorithms,encapsulate each one,and make them interchangeable.）中文解释为：定义一组算法，然后将这些算法封装起来，以便它们之间可以互换，属于一种对象行为型模式。总的来说策略模式是一种比较简单的模式，听起来可能有点费劲，其实就是定义一组通用算法的上层接口，各个算法实现类实现该算法接口，封装模块使用类似于 Context 的概念，Context 暴漏一组接口，Context 内部接口委托到抽象算法层。

是不是每个字都能看懂，拼到一块不知所以然了。最初看到这句话时也不知道啥意思，下面有一个类图供大家看下：

组成角色很简单，对于新手来说，实现起来可能会毫无思路。其实主要使用的就是多态的特性。

实现

了解了基本概念之后，可能对策略模式仅仅是一个了解的状态，动手实操可能还没有什么思路。下面以我的AI项目AIBOT中图片生成功能来说一下策略模式是如何落地的。

先看一下具体的功能点：

目前AI作图只有两个功能，文生图和人像重绘，如何实现这两个功能呢？

普通实现方式

最简单高效的方法是平铺直叙的写代码，通过 if-else 来区分具体是哪个功能，例如：

    @PostMapping("/genImg")
    public ResponseKit<Object> genImg(int type) {
        if (type == 1) {
            // 文生图逻辑
        } else if (type == 2) {
            // 人像重绘逻辑
        } else if (type == ...) {
            // 其他图像生成逻辑
        }
    }

优点

代码实现方便，不需要做过多设计
代码条理比较清晰，自上而下很容易找出来哪块逻辑实现的是什么功能

缺点

会增加类的复杂性，这些逻辑虽都是图片生成，但具体实现逻辑不是同一类，都放到同一个类中，会使这个类变得大而全，与 职责单一 的设计规范相冲突
如果日后需要增加其他图像生成逻辑，需要频繁的修改这个类，而这个类中又有太多其他生成规则的逻辑，修改、新增逻辑可能会对其他已有逻辑造成意料之外的影响，为了避免这种影响可能引入的错误，我们就要对受影响的逻辑都要进行回归测试。这样无形间增加了测试的工作量，与 开闭原则 设计规范相冲突

策略模式实现

依据上面的类图，我们先一步步通过策略模式来实现功能，然后来看一下策略模式有什么优缺点

首先我们需要先定义一个通用接口：

public interface GenImgStrategy {
    ResponseKit<Object> genImg();
}

接口很简单，就一个抽象方法：生成图片；然后我们定义一下文生图和人像重绘的具体实现逻辑。这两个逻辑都统一实现 GenImgStrategy 接口：

public class TextToImgStrategyImpl implemets GenImgStrategy {
    @Override
    public ResponseKit<Object> gen() {
  	// 文生图具体实现逻辑
    }
}

public class GenImgStyleStrategyImpl implemets GenImgStrategy {
    @Override
    public ResponseKit<Object> gen() {
  	// 人像重绘具体实现逻辑
    }
}

定义好了接口和实现类之后，我们如何通过 API 接口中的 type 参数来确定需要执行文生图的逻辑还是执行人像重绘的逻辑呢？这时候我们需要一个辅助类：

public class GenImgStrategyContext {

    private static final Map<Integer, GenImgStrategy> map = new HashMap<>();

    static {
	// 初始化
        map.put(1, new TextToImgStrategyImpl());
        map.put(2, new GenImgStyleStrategyImpl());
  	map.put(..., ...);
    }

    // type=1：执行文生图逻辑；type=2：执行人像重绘逻辑
    public ResponseKit<Object> doGen(Integer type) {
        GenImgStrategy genImgStrategy = map.get(type);
        if (genImgStrategy == null) {
            log.error("类型异常，type={}", type);
            return ResponseKit.error("参数异常");
        }
        return genImgStrategy.gen();
    }
}

这里使用多态的特性，在执行 doGen 方法的时候，通过 type 值来获取不同策略的具体实现类，最后执行 gen 方法的时候，其实执行的是具体实现类中的方法

API 接口只需要改为以下形式，就可以轻松调用不同的图像生成逻辑了：

    @PostMapping("/genImg")
    public ResponseKit<Object> genImg(int type) {
       GenImgStrategyContext context = new GenImgStrategyContext();
       return context.doGen(type);
    }

这样改造之后，我们就通过策略模式来实现了图片生成的两种实现逻辑，后续如果有新的图片生成逻辑，只需要再增加一个实现类，在 context 类的 map 中再增加一种类型即可，对现有的两种实现逻辑实现了零侵入，做功能验证的时候只需要验证新增的逻辑即可，无需担心对现有功能的其他影响。

综合以上，我们看一下策略模式的优缺点：