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