这是我参与「第五届青训营 」伴学笔记创作活动的第 8 天
个人理解下乱写的小故事，若有不对请读者指正。
小白看着眼前的祖传代码和产品发来的新需求，眼前一阵阵发晕。
哦，原来是之前留下的积分加分系统。什么消费100送2分，消费200送5分……突然一个需求叫小白全都提高下门槛，改成150+2，250+5……
好嘛，三天改五次，次次都要动这坨if-else……就不能想个办法让这些不得不做重复劳动的小白郁闷地想着，有没有什么办法让开发和业务方分开，让要改变需求的只要改变输入参数，就能够生成相应的结果呢？
if(){
}else if (){
}else if (){
}else if() {
}
……
……
……
目的：将逻辑代码和业务代码进行解耦： 研发人员（不需懂业务）开发维护程序部分，同时测试通过后，后续不会经常变化改动； 业务人员可直接管理这些业务规则，同时不需要研发人员的参与。
哦，为什么不能像函数重载一样，用策略模式来简化if else的结构呢？针对每一个业务分支写一个策略，完美解决！
策略模式是一种行为设计模式，当一个业务有多种需求，而它们仅仅是在行为上有区别，那就可以使用策略模式，把一类应对方法抽象为类，让系统根据需要动态地选择合适的一种。
小白高兴地用上了策略模式来简化if else的代码结构，他舒舒服服地过上了一段时间。可惜好景不长，他调到了一个更大的项目里面，里面有几百上千个分支。这下小白傻眼了，这种情况下，使用策略模式会导致策略类快速膨胀，数量多的惊人，修改维护起来跟if-else不相上下。
那要怎样简化if else结构，让业务逻辑和数据分离的同时分离出的业务逻辑必须比原来的易于维护？
规则引擎是一种嵌入在应用程序中的组件，实现了将业务决策从应用程序代码中分离出来，并使用预定义的语义模块编写业务决策。规则引擎具体执行可以分为接受数据输入，解释业务规则，根据业务规则做出业务决策几个过程。
总而言之，就是把业务人员提出业务规则叫开发人员做出相对应的业务开发，改变成开发人员做出一个配置规则的程序（即规则引擎），由业务人员进行规则的配置，无需依赖开发人员——这就是规则引擎的好处。
