责任链模式与策略模式在售后系统里的实战

本期内容

• 背景
• 责任链模式的应用
• 策略工厂模式的应用
• 综合使用
• 总结

1、背景

随着公司的快速扩张，业务需求迭代速度加快，业务模块越来越多；导致日常整改代码会发现代码臃肿、坑多、难维护、业务代码冗余等等。最主要也是最普遍的问题在于代码逻辑分支过多，对于这类问题，巧妙的使用设计模式，使代码结构更清晰，使代码像机器零件一样可以灵活地组合使用。下面分享一下日常维护代码中遇到的问题以及优化方案。

2、责任链模式的应用

2.1、责任链模式的定义：

责任链模式（chain of Responsibility Pattern)属于行为型模式。是将链中每一个节点看作是一个对象，每个节点处理的请求均不同，且内部自动维护一个下一节点对象。当一个请求从链式的首段发出时，会沿着链的路径依次传递给每一个节点对象，直至有对象处理这个请求为止。

2.2、责任链模式的使用：

在我们日常的业务代码中，不断地校验是不可避免的，业务量增加，校验也越来越多，对于这种多重纵向校验，我们可以采用责任链模式来进行封装优化。

2.2.1、优化前：

首先看下普通场景，一个简单的退款校验：

2.2.2、优化后：

接下来我们先对于业务链路进行分层封装（简单的业务模拟，重点不在这里），简单分为以下三层处理者：

参数校验：

权限校验：

退款业务：

接下来便是责任链的抽象封装（重点）Handler：

最终业务层调用效果:：

这样的封装对于日后新增的需求判断只需封装新的节点对象即可，业务层调用干净整洁。

2.3、责任链模式的优点：

• 做到了将请求与处理解耦
• 每一个请求处理者（节点对象）只需关注自己感兴趣的请求进行处理即可，对于不感兴趣的请求直接转发给下一节点对象；
• 具备链式传递处理请求功能，请求发送者无需知晓链路结构，只需等待请求处理结果
• 链路结构灵活，可以通过改变链路结构动态的新增或删减责任
• 易于扩展新的请求处理类（节点），符合开闭原则

2.4、责任链模式的缺点：

• 责任链太长或者处理时间过长，会影响整体性能
• 如果节点对象存在循环引用，会造成死循环，导致系统崩溃

其实在权限安全校验框架中，例如：Spring Security、Apache Shiro大量使用责任链，感兴趣的同学可以研究一下。

3、策略工厂模式的应用

3.1、策略模式定义：

策略模式（Strategy Pattern)又叫也叫政策模式（Policy Pattern)，属于行为型模式。它是将定义的算法家族分别封装起来，让他们之间可以互相替换，从而让算法的变化不会影响到使用算法的用户。

3.2、策略模式的使用：

3.2.1、优化前：

在优化订单支付回调的场景中，订单种类繁多，不同类型订单回调逻辑不一致，判断过多：

3.2.2、优化后：

抽象类/接口封装抽象行为：

具体实现业务：

上下文：

调用方：

类图：

以上便是一个标准的策略模式封装。但是这样的封装是没有灵魂的，依然没有去除掉可恶的if..else语句，那么怎么办呢？这时候需要一个策略工厂来作为上下文：

最终调用：

最终类图：

以上便是策略工厂模式的一个实际应用场景，去除了多重判断逻辑，并且新增业务场景只需维护策略以及工厂即可，调用方几乎不用改动。

3.3、策略模式的优点：

• 策略模式的符合开闭原则。
• 避免使用多重条件转移语句，如if...else...和switch语句
• 使用策略模式可以提高算法的保密性和安全性

3.4、策略模式的缺点：

• 调用方必须知道所有的策略，并且自行决定使用哪一策略类
• 代码中会产生非常多策略类，增加维护难度

对源码感兴趣的同学可以发现源码中很多都采取了策略模式的封装例如：org.assertj.core.internal.ComparisonStrategy等等，感兴趣可自行寻找。

4、综合使用

策略模式与责任链模式实际综合应用思路如图所示：

在实际的售后系统应用中，责任链模式与策略模式从横向和纵向将所有的功能模块进行切分，灵活地对所有功能进行组合使用，快速的集成实现业务；即使有新的场景与业务，也可以将场景进行分割，通过新增策略或者责任块快速开发，响应业务！同时整个代码的观感大大提高，逻辑更加清晰，代码的耦合性也不会随业务扩展而增加。

5、总结

对于设计模式的应用还有很多，篇幅有限不再过多介绍，设计模式切忌刻意而为之，顺其自然水到渠成才是上上之策；了解设计模式也有利于加深对于源码的理解，源码中对于设计模式的运用更是家常便饭。知其然知其所以然，了解并且多多运用，使用设计模式可以使枯燥的业务代码变的有趣雅观起来，写的人和读的人皆乐趣无穷。