优化冗余的if-else，“责任树模式”是个不错的选择

简介：写业务逻辑时，if-else 可能是最容易想到的逻辑方式了。然而大量堆砌的 if-else 毫无疑问将给代码维护带来巨大的困难。如何优化这些 if-else 呢？本文分享一种设计模式——责任树模式，通过将责任链与策略模式融合，成为一种广义的责任链模式，不仅可以完成任务的逐级委托，也可以在任一级选择不同的下游策略进行处理，并将责任树模式抽象出一个通用的框架。 

扪心自问，你在写业务代码时是不是也习惯狂堆 if-else 呢？

一 问题背景

最近开发了一个需求，该接口需要根据 p1、p2、p3、version 多个入参的不同组合按照其对应的业务策略给出结果数据。由于该接口已经开发了三期了，每次开发新一期的需求时为了兼容老的业务逻辑，大家都倾向于不删不改只新增，因此这块代码已经产生了一些“坏味道”，函数入口通过不断添加“卫语句”判断 version 的方式跳转到新一期的业务逻辑方法中，而每一期的业务逻辑也是通过 p1、p2、p3 的 if-else 组合形成不同的分支逻辑。这已经是我简化后的表述，总之刚开始对于我这个新同学来说，梳理这块业务代码着实花了一些功夫。

而且，这块逻辑相当于是一个业务上的通用能力，未来一定还会有五期、六期、N 期的需求进来，入参的取值也会不断拓展，因此以现有方式膨胀下去只会“坏味道”会越来越重。  

总结一下，当前场景面临的问题是：

如何解决接口升级，在保证兼容老版本的情况下轻松开发新版本业务逻辑？

如何根据入参 p1、p2、p3 等的不同组合进行策略定位？

二 解决思路

在思考解决方案时，很容易想到两种可以优化类似场景的设计模式：责任链模式和策略模式。

1 责任链模式

责任链模式是实现了类似“流水线”结构的逐级处理，通常是一条链式结构，将“抽象处理者”的不同实现串联起来：如果当前节点能够处理任务则直接处理掉，如果无法处理则委托给责任链的下一个节点，如此往复直到有节点可以处理这个任务。

我们可以通过责任链模式完成对不同 version 业务逻辑隔离的处理，比如节点 1 处理 version = 1 的请求，节点 2 处理 version = 2 的请求等等。但问题在于我们遇到的场景还需要根据一定策略，路由到不同的下游节点进行处理。这就是策略模式擅长解决的问题了。

2 策略模式 

策略模式的目的是将算法的使用与定义解耦，能够实现根据规则路由到不同策略类进行处理。

我们可以通过策略模式解决根据不同参数组合执行不同业务逻辑的场景。但是我们的场景仅仅通过一层策略路由无法满足任务处理需求。请求的分层处理又是责任链模式所擅长的了。 

可以看到，两种设计模式都不完全符合目前这个场景：责任链模式可以实现逐级委托，