一天, 朱斯参加了一场 code Review 研讨会. 会上的一群人正在讨论着如何对祖传代码进行变更, 大家你一言, 我一语, 场面十分热闹!
突然, 只见人群中的一个人满面愁容, 说道:"昨天在项目中看到下面这样一段代码, 分支太多了! 维护起来很烦啊!"
- if(day == "周一"){
- System.out.println("I will play basketball");
- }else if (day == "周二"){
- System.out.println("I will do shopping");
- }else if (day == "周三"){
- System.out.println("I will wash clothes");
- }else if(...) {
- ...
- }// 很烦, 写不下去了
研讨会上的另一个人提道:"这个容易啊, 可以用策略模式来简化 if else 的结构! 毕竟策略模式强调的就是数据与业务逻辑分离, 针对每一个分支写一个策略就好啦!"
可是, 旁边的一个人说道:"用策略模式来简化 if else 的代码结构固然可以, 但是这里有一个前提, 就是分支比较少, 一般就十来个分支差不多了, 可以用策略模式来简化! 但是如果我有上万个分支呢? 你难道做上万个策略? 就算这几万个策略真给你写出来了, 你以后怎么维护? 以后要修改策略, 改完再重新部署一次么? 太不灵活了啊!"
此时, 刚好有一位 DBA 大神也参加了这场 code Review 研讨会! 他说道:"要不考虑一下存储过程? 将变化的策略放在存储过程里维护, 这样至少修改了策略, 不用部署原来的应用!"
听到这里, 朱斯实在听不下去了, 猛的回了一句:"不行! 不行! 用存储过程可读性更差, 而且性能还不好! 更可怕的是, 如果你用的是 MySQL, 调试存储过程是会要人命的!"
"唉, 这也不行, 那也不行, 究竟该怎么办?" 人群中充斥着吵闹声!
朱斯摆了摆手, 示意大家静静, 说道:" 我们需要明白现在的需求是什么?
第一, 我们要简化 if else 结构, 让业务逻辑和数据分离!
第二, 分离出的业务逻辑必须要易于编写, 至少单独编写这些业务逻辑, 要比写代码快!
第三, 分离出的业务逻辑必须要比原来的代码更容易读懂!
第四, 分离出的业务逻辑必须比原来的易于维护, 至少改动这些逻辑, 应用程序不用重启!
大概, 就上面四点吧!"大家问道" 有满足这样需求的中间件么?"朱斯说道:" 有的! 那就是规则引擎! 在一些强大的规则引擎中, 可以像下面这样优化, 使数据和逻辑分离!"
朱斯补充道:"像上面这张图这样, 我们将业务逻辑抽取到单独的规则文件里进行维护, 实现了业务和数据分离! 至于数据如何传入规则引擎呢, 注意看代码里有一句叫 kieSession.insert(" 星期一 "), 这样规则引擎就知道自己有一个字符串内容为星期一的入参! 而且, 大家注意看哦, 规则文件内容是可以用中文编写的!"
"哇塞, 还能用中文来表述业务逻辑! 这样非技术人员也能看得懂呀!" 人群中传来一阵惊叹声!
(ps: 笔者的同事, 当年第一次见到我写的中文业务逻辑, 他一脸的神奇!~)
朱斯补充道:"不仅如此, 当你新加一个条件分支的时候, 直接新增一个规则文件就好啦! 例如, 我们要多加一个判断周二要去 shopping! 那我们就在规则包中新增一个文件, 内容如下!"
- rule "test92"
- when
如果今天是星期二
then
我要去购物
end
"大家看, 我们在规则包中新增上述规则文件后, 你只要让你的应用程序从新加载一次规则包就好啦! 完全不用重启原来的应用程序!" 朱斯说完话, 面带笑容的看着大家.
众人看着朱斯的讲解, 纷纷称奇!
突然, 人群中一阵沸腾, 问道 "哇哇哇, 真是太神奇了, 快告诉我们这套规则引擎叫啥!"
"我叫朱斯 (Drools), 刚才展示的那套规则语言是我的领域特殊语言 (DSL)!"
来源: https://www.cnblogs.com/rjzheng/p/10996186.html