if-else嵌套太深?教你一个新手都能掌握的设计模式搞定!

作者 l 南山狮

来源 l Hollis（ID：hollischuang）

我也不用设计模式

很多人觉得自己写的是业务代码，按照逻辑写下去，再把公用的方法抽出来复用就可以了，设计模式根本就没必要用，更没必要学。

一开始的时候，我也是这么想，直到我遇到。。。

举个栗子

我们先看一个普通的下单拦截接口。

基本逻辑，参数安全拦截，次数拦截，规则拦截，都通过，返回允许下单，任意一个失败，返回对应的失败原因。

多层嵌套if写法

我们正常多层嵌套if的写法

异常处理逻辑

或者有些利用异常做逻辑，代码会简单一点

一开始，我就直接使用异常来做逻辑。但后续逻辑越来越复杂之后，也会出现一些问题。例如异常只能返回异常信息，不能返回更多的字段信息。

后面也留意到，异常做逻辑，在阿里规范是禁止的。

阿里代码规范 ：
【强制】异常不要用来做流程控制，条件控制。
说明：异常设计的初衷是解决程序运行中的各种意外情况，且异常的处理效率比条件判断方式要低很多。

更重要的是，代码可读性太差了，随时一个方法的异常抛出来，还要考虑代码本身的异常。

没更好的办法，只能考虑设计模式了

怎么改，会使代码的可读性高，扩展性好？

在同事的提醒下，突然想起了设计模式！

我们希望达到的目的

1. 代码没有这么多if else嵌套，可读性高
2. 如果新增新的拦截逻辑简单方便，不影响原本的逻辑，扩展性好
3. 可以很方便地调换拦截逻辑顺序，低耦合

责任链模式

在这种场景下，非常适合责任链模式。（什么场景使用什么设计模式，这就需要平时有积累，知道各种设计模式的基本使用）

责任链，顾名思义，就是用来处理相关事务责任的一条执行链，执行链上有多个节点，每个节点都有机会（条件匹配）处理请求事务，如果某个节点处理完了就可以根据实际业务需求传递给下一个节点继续处理或者返回处理完毕。

首先，建立过滤器的抽象类

过滤器的实现类

使用Order注解，确定过滤器的顺序，后续在spring注入的时候，会有奇效

使用设计模式的好处

看下使用责任链模式后，有什么好处！

1. 新增拦截逻辑，只需要再实现一个AbstractFilter类即可
2. 修改拦截顺序，只需要修改Order注解的大小，越小，优先级越高
3. 代码清晰，所有处理逻辑下沉到实现类中

使用设计模式的缺点

做到了低耦合，高扩展。但也带来了一些不好的地方

1. 逻辑更复杂，用了链式等数据结构，要注意单例的问题，不能重复使用
2. 类数量激增，一个拦截器就一个类

最后小结一下

不是什么地方都适合使用设计模式，如果逻辑简单，你硬要使用设计模式，只会带来结构上的复杂，大家可以按照大家的业务场景来使用。