乐趣区

关于后端:新来的同事用策略模式把if-else给优化了技术总监说能不能想好了再改

作者：

jiezi

在

我想大家必定都或多或少的看过各种“策略模式”的解说、布道等等，这篇文章就是来好好“廓清”一下策略模式，并尝试答复以下的问题：

策略模式是如何优化业务逻辑代码构造的？
杀鸡焉用宰牛刀？就是几个if else场景我须要用到策略模式？！
有没有什么更好的代码构造来实现策略模式的吗？

策略模式是如何优化业务逻辑代码构造的？
要答复这个问题，咱们还得先扒一扒策略模式的定义，从定义着手来了解它
策略模式的教科书定义
它的定义很精简：一个类的行为或其算法能够在运行时更改。咱们把它降维到代码层面，用人话翻译一下就是，运行时我给你这个类的办法传不同的“key”，你这个办法会执行不同的业务逻辑。细品一下，这不就是 if else 干的事吗？

策略模式优化了什么？
其实策略模式的核心思想和 if else一模一样，依据不同的key动静的找到不同的业务逻辑，那它就只是如此吗？
实际上，咱们口中的策略模式其实就是在代码构造上调整，用接口+实现类+分派逻辑来使代码构造可维护性好点。

个别教科书上解说到接口与实现类就完结了，其余博客上会带上提及分派逻辑。这里就不啰嗦了。
小结一下，即应用了策略模式，你该写的业务逻辑照常写，到逻辑分派的时候，还是变相的if else。而它的优化点是形象了出了接口，将业务逻辑封装成一个一个的实现类，任意地替换。在简单场景（业务逻辑较多）时比间接 if else 来的好保护些。
杀鸡焉用宰牛刀？就是几个if else场景我须要用到策略模式？！
我想小伙伴们常常有这样的不满，我的业务逻辑就3 4 行，你给我整一大堆类定义？有必要这么麻烦吗？我看具体的业务逻辑还须要去不同的类中，简略点行不行。
其实咱们所不满的就是策略模式带来的毛病：
1、策略类会增多 2、业务逻辑扩散到各个实现类中，而且没有一个中央能够仰视整个业务逻辑
针对传统策略模式的毛病，在这分享一个实现思路，这个思路曾经帮咱们团队解决了多个简单if else的业务场景，了解上比拟容易，代码上须要用到Java8的个性——利用Map与函数式接口来实现。
间接show代码构造：为了简略演示一个思路，代码用String 类型来模仿一个业务BO
其中： 1. getCheckResult() 为传统的做法 2. getCheckResultSuper()则当时在Map中定义好了“判断条件”与“业务逻辑”的映射关系,具体解说请看代码正文
/**

  • 某个业务服务类
    */

@Service
public class BizService {

/**
 * 传统的 if else 解决办法
 * 当每个业务逻辑有 3 4 行时，用传统的策略模式不值得，间接的if else又显得不易读
 */
public String getCheckResult(String order) {
    if ("校验1".equals(order)) {
        return "执行业务逻辑1";
    } else if ("校验2".equals(order)) {
        return "执行业务逻辑2";
    }else if ("校验3".equals(order)) {
        return "执行业务逻辑3";
    }else if ("校验4".equals(order)) {
        return "执行业务逻辑4";
    }else if ("校验5".equals(order)) {
        return "执行业务逻辑5";
    }else if ("校验6".equals(order)) {
        return "执行业务逻辑6";
    }else if ("校验7".equals(order)) {
        return "执行业务逻辑7";
    }else if ("校验8".equals(order)) {
        return "执行业务逻辑8";
    }else if ("校验9".equals(order)) {
        return "执行业务逻辑9";
    }
    return "不在解决的逻辑中返回业务谬误";
}

/**
 * 业务逻辑分派Map
 * Function为函数式接口，上面代码中 Function<String, String> 的含意是接管一个Stirng类型的变量，返回一个String类型的后果
 */
private Map<String, Function<String, String>> checkResultDispatcher = new HashMap<>();

/**
 * 初始化 业务逻辑分派Map 其中value 寄存的是 lambda表达式
 */
@PostConstruct
public void checkResultDispatcherInit() {
    checkResultDispatcher.put("校验1", order -> String.format("对%s执行业务逻辑1", order));
    checkResultDispatcher.put("校验2", order -> String.format("对%s执行业务逻辑2", order));
    checkResultDispatcher.put("校验3", order -> String.format("对%s执行业务逻辑3", order));
    checkResultDispatcher.put("校验4", order -> String.format("对%s执行业务逻辑4", order));
    checkResultDispatcher.put("校验5", order -> String.format("对%s执行业务逻辑5", order));
    checkResultDispatcher.put("校验6", order -> String.format("对%s执行业务逻辑6", order));
    checkResultDispatcher.put("校验7", order -> String.format("对%s执行业务逻辑7", order));
    checkResultDispatcher.put("校验8", order -> String.format("对%s执行业务逻辑8", order));
    checkResultDispatcher.put("校验9", order -> String.format("对%s执行业务逻辑9", order));
}

public String getCheckResultSuper(String order) {
    //从逻辑分派Dispatcher中取得业务逻辑代码，result变量是一段lambda表达式
    Function<String, String> result = checkResultDispatcher.get(order);
    if (result != null) {
        //执行这段表达式取得String类型的后果
        return result.apply(order);
    }
    return "不在解决的逻辑中返回业务谬误";
}

}
复制代码

通过http调用一下看看成果：
/**

  • 模仿一次http调用
    */

@RestController
public class BizController {

@Autowired
private BizService bizService;

@PostMapping("/v1/biz/testSuper")
public String test2(String order) {
    return bizService.getCheckResultSuper(order);
}

}复制代码

这是个简略的demo演示，之后会举一些简单的场景案例。
鲁迅曾说过，“每解决一个问题，就会因出更多的问题”。咱们一起来看看这样的实现有什么益处，会带来什么问题。

益处很直观：

在一段代码里直观的看到”判断条件”与业务逻辑的映射关系
不须要独自定义接口与实现类，间接应用现有的函数式接口（什么？不晓得函数式接口？快去理解），而实现类间接就是业务代码自身。

不好的点： 1. 须要团队成员对lambda表达式有所理解(什么？Java14都进去了还有没用上Java8新个性的小伙伴？)
接下来我举几个在业务中常常遇到的if else场景，并用Map+函数式接口的形式来解决它
在实在业务场景问题的解决思路
有的小伙伴会说，我的判断条件有多个啊，而且很简单，你之前举个例子只有单个判断逻辑，而我有多个判断逻辑该怎么办呢？
很好解决：写一个判断逻辑的办法，Map的key由办法计算出
/**

  • 某个业务服务类
    */

@Service
public class BizService {

private Map<String, Function<String, String>> checkResultDispatcherMuti = new HashMap<>();

/**
 * 初始化 业务逻辑分派Map 其中value 寄存的是 lambda表达式
 */
@PostConstruct
public void checkResultDispatcherMuitInit() {
    checkResultDispatcherMuti.put("key_订单1", order -> String.format("对%s执行业务逻辑1", order));
    checkResultDispatcherMuti.put("key_订单1_订单2", order -> String.format("对%s执行业务逻辑2", order));
    checkResultDispatcherMuti.put("key_订单1_订单2_订单3", order -> String.format("对%s执行业务逻辑3", order));
}

public String getCheckResultMuti(String order, int level) {
    //写一段生成key的逻辑：
    String ley = getDispatcherKey(order, level);

    Function<String, String> result = checkResultDispatcherMuti.get(ley);
    if (result != null) {
        //执行这段表达式取得String类型的后果
        return result.apply(order);
    }
    return "不在解决的逻辑中返回业务谬误";
}

/**
 * 判断条件办法
 */
private String getDispatcherKey(String order, int level) {
    StringBuilder key = new StringBuilder("key");
    for (int i = 1; i <= level; i++) {
        key.append("_" + order + i);
    }
    return key.toString();
}

}
复制代码

用http模仿一下：
/**

  • 模仿一次http调用
    */

@RestController
public class BizController {

@Autowired
private BizService bizService;

@PostMapping("/v1/biz/testMuti")
public String test1(String order, Integer level) {
    return bizService.getCheckResultMuti(order, level);
}

}复制代码

只有设计好你的key的生成规定就好。
还有小伙伴会问：我的业务逻辑有很多很多行，在checkResultDispatcherMuitInit()办法的Map中间接写不会很长吗？
间接写当然长了，咱们能够形象出一个service服务专门放业务逻辑，而后在定义中调用它就好了：
提供一个业务逻辑单元：
/**

  • 提供业务逻辑单元
    */

@Service
public class BizUnitService {

public String bizOne(String order) {
    return order + "各种花式操作1";
}
public String bizTwo(String order) {
    return order + "各种花式操作2";
}
public String bizThree(String order) {
    return order + "各种花式操作3";
}

}
复制代码

/**

  • 某个业务服务类
    */

@Service
public class BizService {

@Autowired
private BizUnitService bizUnitService;

private Map<String, Function<String, String>> checkResultDispatcherComX = new HashMap<>();

/**
 * 初始化 业务逻辑分派Map 其中value 寄存的是 lambda表达式
 */
@PostConstruct
public void checkResultDispatcherComXInit() {
    checkResultDispatcherComX.put("key_订单1", order -> bizUnitService.bizOne(order));
    checkResultDispatcherComX.put("key_订单1_订单2", order -> bizUnitService.bizTwo(order));
    checkResultDispatcherComX.put("key_订单1_订单2_订单3", order -> bizUnitService.bizThree(order));
}

public String getCheckResultComX(String order, int level) {
    //写一段生成key的逻辑：
    String ley = getDispatcherComXKey(order, level);

    Function<String, String> result = checkResultDispatcherComX.get(ley);
    if (result != null) {
        //执行这段表达式取得String类型的后果
        return result.apply(order);
    }
    return "不在解决的逻辑中返回业务谬误";
}

/**
 * 判断条件办法
 */
private String getDispatcherComXKey(String order, int level) {
    StringBuilder key = new StringBuilder("key");
    for (int i = 1; i <= level; i++) {
        key.append("_" + order + i);
    }
    return key.toString();
}

}
复制代码

调用后果：

总结
最初，咱们一起尝试答复以下几个问题： 1. 策略模式是如何优化业务逻辑代码构造的？
形象了出了接口，将业务逻辑封装成一个一个的实现类，任意地替换。在简单场景（业务逻辑较多）时比间接 if else 来的好保护些。

杀鸡焉用宰牛刀？就是几个if else场景我须要用到策略模式？！

咱们所不满的其实就是传统接口实现的毛病： 1、策略类会很多。 2、业务逻辑扩散到各个实现类中，而且没有一个中央能够俯览整个业务逻辑

有没有什么更好的代码构造来实现策略模式的吗？

针对传统策略模式的毛病，分享了利用Map与函数式接口来实现的思路。

评论

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注

这个站点使用 Akismet 来减少垃圾评论。了解你的评论数据如何被处理。

更多文章