【规则引擎】简易规则引擎在菜单权限的应用
背景
在年底，突发奇想，想对公司内部现有的菜单权限进行重新设计。
观察了令人头疼的硬编码后，想出可用规则引擎进行重构。
分析
观察如下代码，硬编码，很临时，很敷衍。但其实用数学或者代数思维理解，就是「取代」。
if (system.contains(1109) && control.contains(1126)) {
control.remove(1126);
}
if (system.contains(1109) && control.contains(1143)) {
control.remove(1143);
}
if (system.contains(1113) && control.contains(1127)) {
control.remove(1127);
}
设计
观察了各种硬编码模式，分析了背后的意图，便总结出来一些范式。
业务范式
「业务范式」是我自己取的概念，也可以用计算机的思维理解，叫做 「关系运算指令」也可以。
例如：
- 是否是公共基础菜单
- 取代
- 管理员必须有
- 管理员不应有
- XX角色应该有
- XX类型用户应该有
- 离职中用户应该有
- 在职用户不应该有
- 普通用户不应该有
- 其他罕见类型
其实都是人类思维。硬生生写成了代码。现在的过程就是反过来按照人类思维总结设计。
规则引擎
以前模模糊糊了解过规则引擎，但这次突然想明白了。
规则引擎定义
规则引擎是一种嵌入在应用程序中的组件，实现了将业务决策从应用程序代码中分离出来，并使用预定义的语义模块编写业务决策。接受数据输入，解释业务规则，并根据业务规则做出业务决策。
规则本质上是一个函数，如y=f(x1,x2,..,xn)
规则引擎由三部分
事实（Fact）：就是用户输入的已经事实，可以理解为推理前的已知对象。
LHS(Left Hand Side)：可以理解为规则执行需要满足的条件。
RHS(Right Hand Sike)：可以理解为规则执行后的返回对象。
理解反思
那么以上的业务范式就隐含了规则引擎的三个部分。
以「取代」为例：
当什么模块下，什么菜单，应该优先于（取代）什么菜单。
事实：模块，或者出现了某个已知的，要被菜单
LHS：执行满足条件，这个条件比较简单，就是假设出现了这个菜单，或者是假设用户是某个角色，有点像邮件整理规则。
RHS: 执行后返回对象，这个就是用什么菜单 去取代之前的菜单。
这个又有点像运算符，或者指令集。
应用
在这个业务场景下，目标非常清晰和简单，就是将原本的编程代码逻辑，反向改成规则描述的通俗易懂的逻辑。
好在这个业务范式足够简单，甚至没有加减乘除。
如果需要一些判断条件，则需要具体对LHS进行设计。
