根据前文，我们知道了对前文需求的一个很好的解决方案：规则引擎。由资料[1]从JSR-94也不难看出在这一块已经有很多研究成果和实现方案。

要说实现，必须先提一下规则引擎的困难：
1.人类对事物的推理方法[2]按照思维的进程方向来看主要有演绎、归纳和类比，在规则引擎中所说的forward-chaining和backward-chaining即是演绎法和归纳法。不管哪一种方法，规则引擎的性能决定于推理算法的效率。forward-chaining是从一个初始的事实出发，不断地应用规则（即进行条件判断，执行相关操作）得出结论。backward-chaining则是从假设出发，不断地寻找符合假设的事实。商用规则引擎多半对如何证实一个事实不那么感兴趣，所以现有的商用规则引擎多是forward-chaining的，而有名的RETE算法[3]就是一个高效率的forward-chaining算法。

2.使用规则引擎相比于普通产品，似乎适应性更强，但规则引擎本身对于产品的适应性则依赖于规则引擎是否足够通用。像Java语言系的JSR-94，使得规则引擎的实现标准化，由此产出的规则引擎也更加通用。

3.许多现有的规则引擎，对于规则的描述有自有一套规则语言，虽然也有标准语言RuleML[4]，为了规则能够重用，基于此不得不再做一套管理规则语言的转换器，规则语言没有标准化之前，规则引擎很难实现标准化。拿资料[5]中所列的三种规则引擎JRules、JBoss Rules（Drools）和Jess来说一下规则语言，它们或者是采用类XML文本混杂程序语言，但依赖于类Antlr这种解释器；或者使用专用程序语言，学习成本高；而且为了能成为产品，对于规则语言，规则引擎需要提供相应的编辑器和管理工具。就好像在规则引擎中集成了一个IDE。

说明一下，对于困难点1，虽然我们不需要构建规则引擎，但规则引擎之争很关键的一点就是规则引擎的性能。对于困难点2和3，本身对使用者而言是否标准并不重要，但重要的是规则引擎的易用性，如果说使用规则引擎需要耗费的学习成本大大高于不使用规则引擎时对产品维护所需要的成本，那么也没有必要引入规则引擎。

这或许可以说是规则引擎的窘境。但不妨我们回归到规则引擎需求。在技术选型时，很关键要做的一步是清楚明了相关技术的适用范围。资料[6]中用例子阐述了规则引擎需求。

即便在最有利的情况下，在软件系统中编写业务规则也是一项必要的挑战性任务。不明确、不完整、易误解的需求的出现只会使开发工作复杂化，并带来成本高昂的错误。业务规则的可视化和文本描述的结合提供了更准确、更有效地捕捉业务规则的途径，特别对于使用规则驱动引擎的实现来说更是如此。使用本文描述的技术，您就可以使用强大的分析框架更好地武装业务分析人员，便于其沟通复杂的业务处理规则。

基于规则引擎需求，对规则引擎做总结如下：
1.当需要在产品运行过程中不断修改规则，而使得重构产品的成本远远大于引入规则引擎的成本时，则适合引入规则引擎
2.规则引擎的规则编辑和管理面向的用户一般是业务人员，所以规则语言要对业务人员足够有好
3.快速匹配条件从而定位到对应的操作是规则引擎高性能的关键
4.规则引擎已经出现标准化，且有多种解决方案，没有必要重复发明轮子，但使用现有规则引擎实现产品仍然有点门槛

综上，再来看看前文中最初始的需求，我们需要实现的是对于复杂step流式的程序进行step和程序的解耦：
1.需要在运行时不断修改规则，但是引入规则引擎成本过高
2.更改规则的用户是程序员（测试脚本的编写者），不用关心是否要弄一套全新的规则语言，以及这套规则语言的解释器
3.总的来说step执行还是一个顺序流，没有必要维护一个匹配树，即不需要引入RETE算法
4.学习规则引擎标准的成本或许高于给出当前需求下的其他解决方案的实现。

后续文中将继续讨论前文中code3中后面engine.exe()部分的实现，也就是这里的其他解决方案。

参考资料
[1]http://www.ibm.com/developerworks/cn/java/j-java-rules/index.html?ca=dwcn-newsletter-java
[2]http://sci-art.cz.cc/?p=46
[3]http://www.cis.temple.edu/~ingargio/cis587/readings/rete.html
[4]http://www.ruleml.org/
[5]http://www.blogjava.net/calvin/archive/2005/10/04/14789.html
[6]http://www.ibm.com/developerworks/cn/opensource/os-rulesengines/index.html