近日在公司领到一个小需求，需要对之前已有的试用用户申请规则进行拓展。我们的场景大概如下所示：
按照上述的条件我们可以得出的结论是：
咱们的主要流程主要是基于 and 或者 or 的关系。
如果有一个不匹配的话，其实咱们后续的流程是不用执行的，就是需要具备一个短路的功能。
对于目前的现状来说，我如果在原有的基础上来改，只要稍微注意一下解决需求不是很大的问题，但是说后面可维护性非常差。
后面经过权衡过后，我还是决定将这个部分进行重构一下。
规则执行器
针对这个需求，我首先梳理了一下咱们规则执行器大概的设计， 然后我设计了一个 V1 版本和大家一起分享一下，如果大家也有这样的case 可以给我分享留言，下面部分主要是设计和实现的流程和 code.
规则执行器的设计
对于规则的抽象并实现规则
执行器构建
执行器的调用
总结
规则执行器的优点和缺点
优点：
比较简单，每个规则可以独立，将规则，数据，执行器拆分出来，调用方比较规整；
我在 Rule 模板类中定义 convert 方法做参数的转换这样可以能够，为特定 rule 需要的场景数据提供拓展。
缺点：
上下 rule 有数据依赖性，如果直接修改公共传输对象 dto这样设计不是很合理，建议提前构建数据。
网友评论