解释器模式

27.1 四则运算你会吗

      在银行、证券类项目中，经常会有一些模型运算，通过对现有数据的统计、分析而预测不可知或未来可能发生的商业行为。模型运算大部分是针对海量数据的，例如建立一个模型公式，分析一个城市的消费倾向，进而影响银行的营销和业务扩张方向，一般的模型运算都有一个或多个运算公式，通常是加减乘除四则运算，偶尔也有指数、开方等复杂运算。具体到一个金融业务中，模型公式是非常复杂的，虽然只有加减乘除四则运算，但是公式有可能有十多个参数，而且上百个业务品各有不同的取参路径，同时相关表的数据量都在百万级，呵呵，复杂了吧，不复杂那就不叫金融业务，我们就来讲讲运算的核心——模型公式，如何实现。

      业务需求：输入一个模型公式（加减四则运算），然后输入模型中的参数，运算出结果。

      设计要求：

• 公式可以运行期编辑，并且符合正常算术书写方式，例如a+b-c；
• 高扩展性，未来增加指数、开方、极限、求导等运算符号时，较少改动量；
• 效率可以不用考虑，晚间批量运算。

      需求不复杂，若仅仅对数字采用四则运算，每个程序员都可以写出来。但是增加了增加模型公式就复杂了。先解释一下为什么需要公式, 而不采用直接计算的方法，例如有如下3个公式：

• 业务种类1的公式：a+b+c-d；
• 业务种类2的公式：a+b+e-d；
• 业务种类3的公式：a-f。

      其中，a、b、c、d、e、f参数的值都可以取得，如果使用直接计算数值的方法需要为每个品种写一个算法，目前仅仅是3个业务种类，那上百个品种呢？歇菜了吧！建立公式，然后通过公式运算才是王道。

      我们以实现加减算法（由于篇幅所限，乘除法的运算读者可以自行扩展）的公式为例，讲解如何解析一个固定语法逻辑。由于使用语法解析的场景比较少，而且一些商业公司（比如SAS、SPSS等统计分析软件）都支持类似的规则运算，亲自编写语法解析的工作已经非常少，以下例程采用逐步分析方法，带领大家了解这一实现过程。

      我们来想，公式中有什么？仅有两类元素：运算元素和运算符号，运算元素就是指a、b、c等符号，需要具体赋值的对象，也叫做终结符号，为什么叫终结符号呢？因为这些元素除了需要赋值外，不需要做任何处理，所有运算元素都对应一个具体的业务参数，这是语法中最小的单元逻辑，不可再拆分；运算符号就是加减符号，需要我们编写算法进行处理，每个运算符号都要对应处理单元，否则公式无法运行，运算符号也叫做非终结符号。两类元素的共同点是都要被解析，不同点是所有的运算元素具有相同的功能，可以用一个类表示，而运算符号则是需要分别进行解释，加法需要加法解析器，减法也需要减法解析器。分析到这里，我们就可以先画一个简单的类图，如图27-1所示。

图27-1 初步分析加减法类图

      很简单的一个类图，VarExpression用来解析运算元素，各个公式能运算元素的数量是不同的，但每个运算元素都对应一个VarExpression对象。SybmolExpression负责运算符号解析，由两个子类AddExpression（负责加法运算）和SubExpression（负责减法运算）来实现。解析的工作完成了，我们还需要把安排运行的先后顺序（加减法是不用考虑，但是乘除法呢？注意扩展性），并且还要返回结果，因此我们需要增加一个封装类来进行封装处理，由于我们只做运算，暂时还不与业务有关联，定义为Calculator类，分析到这里，思路就比较清晰了，优化后加减法类图如图27-2所示。

图27-2 优化后加减法类图

      Calcuator的作用是封装，根据迪米特原则，Client只与直接的朋友Calcuator交流，与其他类没关系。整个类图的结构也比较清晰，于是我们开始填充类图中的方法，完整类图如图27-3所示。

图27-3 完整加减法类图

      类图已经完成，我们来看代码实现。Expression抽象类如代码清单27-1所示。

代码清单27-1 抽象表达式类

public abstract class Expression {

//解析公式和数值,其中var中的key值是是公式中的参数，value值是具体的数字

public abstract int interpreter(HashMap<String,Integer> var);

}

      抽象类非常简单，仅一个方法interpreter负责对对传递进来的参数和值进行解析和匹配，其中输入参数为HashMap类型，key值为模型中的参数，如a、b、c等，value为运算时取得的具体数字。

变量的解析器如代码清单27-2所示。

代码清单27-2 变量解析器

public class VarExpression extends Expression {

private String key;

public VarExpression(String _key){

this.key = _key;

}

//从map中取之

public int interpreter(HashMap<String, Integer> var) {

return var.get(this.key);

}

}

      抽象运算符号解析器如代码清单27-3所示。

代码清单27-3 抽象运算符号解析器

public abstract class SymbolExpression extends Expression {

protected Expression left;

protected Expression right;

//所有的解析公式都应只关心自己左右两个表达式的结果

public SymbolExpression(Expression _left,Expression _right){

this.left = _left;

this.right = _right;

}

}

      这个解析过程还是比较有意思的，每个运算符号都只和自己左右两个数字有关系，但左右两个数字有可能也是一个解析的结果，无论何种类型，都是Expression的实现类，于是在对运算符解析的子类中增加了一个构造函数，传递左右两个表达式。具体的加、减法解析器如代码清单27-4、27-5所示。

代码清单27-4 加法解析器

public class AddExpression extends SymbolExpression {

public AddExpression(Expression _left,Expression _right){

super(_left,_right);

}

//把左右两个表达式运算的结果加起来

public int interpreter(HashMap<String, Integer> var) {

return super.left.interpreter(var) + super.right.interpreter(var);

}

}

代码清单27-5 减法解析器

public class SubExpression extends SymbolExpression {

public SubExpression(Expression _left,Expression _right){

super(_left,_right);

}

//左右两个表达式相减

public int interpreter(HashMap<String, Integer> var) {

return super.left.interpreter(var) - super.right.interpreter(var);

}

}

      解析器的开发工作已经完成了，但是需求还没有完全实现，我们还需要对解析器进行封装，封装类Calculator如代码清单27-6所示。

代码清单27-6 解析器封装类

public class Calculator {

//定义的表达式

private Expression expression;

//构造函数传参,并解析

public Calculator(String expStr){

//定义一个堆栈，安排运算的先后顺序

Stack<Expression> stack = new Stack<Expression>();

//表达式拆分为字符数组

char[] charArray = expStr.toCharArray();

//运算

Expression left = null;

Expression right = null;

for(int i=0;i<charArray.length;i++){

switch(charArray[i]) {

case '+': //加法

//加法结果放到堆栈中

left = stack.pop();

right = new VarExpression(String.valueOf(charArray[++i]));

stack.push(new AddExpression(left,right));

break;

case '-':

left = stack.pop();

right = new VarExpression(String.valueOf(charArray[++i]));

stack.push(new SubExpression(left,right));

break;

default: //公式中的变量

stack.push(new VarExpression(String.valueOf(charArray[i])));

}

}

//把运算结果抛出来

this.expression = stack.pop();

}

//开始运算

public int run(HashMap<String,Integer> var){

return this.expression.interpreter(var);

}

}

      方法比较长，我们来分析一下，Calculator构造函数接收一个表达式，然后把表达式转化为char数组，并判断运算符号，如果是“+”则进行加法运算，把左边的数（left变量）和右边的数（right变量）加起来就可以了，那左边的数为什么是在堆栈中呢？例如这个公式：a+b-c，根据for循环，首先被压入堆栈中的应该是有a元素生成的VarExpression对象，然后判断到加号时，把a元素的对象VarExpression从堆栈中弹出，与右边的数组b进行相加，b又是怎么得来的呢？当前的数组游标下移一个单元格即可，同时为了防止该元素再次被遍历，则通过++i的方式跳过下一个遍历——于是一个加法的运行结束。减法也是相同的运行原理。

      为了满足业务要求，我们设置了一个Client类来模拟用户情况，用户要求可以扩展，可以修改公式，那就通过接收键盘事件来处理，Client类如代码清单27-7所示。

代码清单27-7 客户模拟类

public class Client {

//运行四则运算

public static void main(String[] args) throws IOException{

String expStr = getExpStr();

//赋值

HashMap<String,Integer> var = getValue(expStr);

Calculator cal = new Calculator(expStr);

System.out.println("运算结果为："+expStr +"="+cal.run(var));

}

//获得表达式

public static String getExpStr() throws IOException{

System.out.print("请输入表达式：");

return (new BufferedReader(new InputStreamReader(System.in))).readLine();

}

//获得值映射

public static HashMap<String,Integer> getValue(String exprStr) throws IOException{

HashMap<String,Integer> map = new HashMap<String,Integer>();

//解析有几个参数要传递

for(char ch:exprStr.toCharArray()){

if(ch != '+' && ch != '-'){

//解决重复参数的问题

if(!map.containsKey(String.valueOf(ch))){ System.out.print("请输入"+ch+"的值:");

String in = (new BufferedReader(new InputStreamReader(System.in))).readLine();

map.put(String.valueOf(ch),Integer.valueOf(in));

}

}

}

return map;

}

}

      其中，getExpStr是从键盘事件中获得的表达式，getValue方法是从键盘事件中获得表达式中的元素映射值，运行过程如下。

      首先，要求输入公式。

请输入表达式：a+b-c

      其次，要求输入公式中的参数。

请输入a的值:100

请输入b的值:20

请输入c的值:40

      最后，运行出结果。

运算结果为：a+b-c=80

      看，要求输入一个公式，然后输入参数，运行结果出来了！那我们是不是可以修改公式？当然可以了，我们只要输入公式，然后输入相应的值就可以了，公式是在运行期定义的，而不是在运行前就制定好的，是不是类似于初中学过的“代数”这门课？先公式，然后赋值，运算出结果。

      需求已经开发完毕，公式可以自由定义，只要符合规则（有变量有运算符合）就可以运算出结果；若需要扩展也非常容易，只要增加SymbolExpression的子类就可以了 ，这就是解释器模式。

27.2 解释器模式的定义

      解释器模式（Interpreter Pattern）是一种按照规定语法进行解析的方案，在现在项目中使用较少（谁没事干会去写一个PHP或者Ruby的解析器），其定义如下：Given a language, define a representation for its grammar along with an interpreter that uses the representation to interpret sentences in the language。给定一个语言, 定义它的文法的一种表示，并定义一个解释器，该解释器使用该表示来解释语言中的句子。

      解释器模式的通用类图如图27-4所示。

图27-4 解释器模式通用类图

• AbstractExpression 抽象解释器

      具体的解释任务由各个实现类完成，具体的解释器分别由TerminalExpression和NonterminalExpression完成。

• TerminalExpression终结符表达式

      实现与文法中的元素相关联的解释操作，通常一个解释器模式中只有一个终结符表达式，但有多个实例，对应不同的终结符。具体到我们例子就是VarExpression类，表达式中的每个终结符都在堆栈中产生了一个VarExpression对象。

• NonterminalExpression 非终结符表达式

      文法中的每条规则对应于一个非终结表达式，具体到我们的例子就是加减法规则分别对应到AddExpression和SubExpression两个类。非终结符表达式根据逻辑的复杂程度而增加，原则上每个文法规则都对应一个非终结符表达式。

• Context 环境角色

      具体到我们的例子中是采用HashMap代替。

      解释器是一个比较少用的模式，以下为其通用源码，可以作为参考。抽象表达式通常只有一个方法，如代码清单27-8所示。

代码清单27-8 抽象表达式

public abstract class Expression {

//每个表达式必须有一个解析任务

public abstract Object interpreter(Context ctx);

}

      抽象表达式是生成语法集合（也叫做语法树）的关键，每个语法集合完成指定语法解析任务，它是通过递归调用的方式，最终由最小的语法单元进行解析完成。终结符表达式如代码清单27-9所示。

代码清单27-9 终结符表达式

public class TerminalExpression extends Expression {

//通常终结符表达式只有一个，但是有多个对象

public Object interpreter(Context ctx) {

return null;

}

}

      通常，终结符表达式比较简单，主要是处理场景元素和数据的转换。

非终结符表达式如代码清单27-10所示。

代码清单27-10 非终结符表达式

public class NonterminalExpression extends Expression {

//每个非终结符表达式都会对其他表达式产生依赖

public NonterminalExpression(Expression... expression){

}

public Object interpreter(Context ctx) {

//进行文法处理

return null;

}

}

      每个非终结符表达式都代表了一个文法规则，并且每个文法规则都只关心自己周边的文法规则的结果（注意是结果），因此这就产生了每个非终结符表达式调用自己周边的非终结符表达式，然后最终、最小的文法规则就是终结符表达式，终结符表达式的概念就是如此，不能够再参与比自己更小的文法运算了。

客户类如代码清单27-11所示。

代码清单27-11 客户类

public class Client {

public static void main(String[] args) {

Context ctx = new Context();

//通常定一个语法容器，容纳一个具体的表达式，通常为ListArray,LinkedList,Stack等类型

Stack<Expression> stack = null; 

for(;;){

//进行语法判断，并产生递归调用

}

//产生一个完整的语法树，由各各个具体的语法分析进行解析

Expression exp = stack.pop();

//具体元素进入场景

exp.interpreter(ctx);

}

}

      通常Client是一个封装类，封装的结果就是传递进来一个规范语法文件，解析器分析后产生结果并返回，避免了调用者与语法解析器的耦合关系。

27.3 解释器模式的应用

27.3.1 解释器模式的优点

      解释器是一个简单语法分析工具，它最显著的优点就是扩展性，修改语法规则只要修改相应的非终结符表达式就可以了，若扩展语法，则只要增加非终结符类就可以了。

27.3.2 解释器模式的缺点

• 解释器模式会引起类膨胀

      每个语法都要产生一个非终结符表达式，语法规则比较复杂时，就可能产生大量的类文件，为维护带来了非常多的麻烦。

• 解释器模式采用递归调用方法

      每个非终结符表达式只关心与自己有关的表达式，每个表达式需要知道最终的结果，必须一层一层地剥茧，无论是面向过程的语言还是面向对象的语言，递归都是在必要条件下使用的，它导致调试非常复杂。想想看，如果要排查一个语法错误，我们是不是要一个一个断点的调试下去，直到最小的语法单元。

• 效率问题

      解释器模式由于使用了大量的循环和递归，效率是个不容忽视的问题，特别是用于解析复杂、冗长的语法时，效率是难以忍受的。

27.3.3 解释器模式使用的场景

• 重复发生的问题可以使用解释器模式

      例如，多个应用服务器，每天产生大量的日志，需要对日志文件进行分析处理，由于各个服务器的日志格式不同，但是数据要素是相同的，按照解释器的说法就是终结符表达式都是相同的，但是非终结符表达式就需要制定了。在这种情况下，可以通过程序来一劳永逸地解决该问题。

• 一个简单语法需要解释的场景

      为什么是简单？看看非终结表达式，文法规则越多，复杂度越高，而且类间还要进行递归调用（看看我们例子中的堆栈），不是一般地复杂。想想看，多个类之间的调用你需要什么样的耐心和信心去排查问题。因此，解释器模式一般用来解析比较标准的字符集，例如SQL语法分析，不过该部分逐渐被专用工具所取代。

      在某些特用的商业环境下也会采用解释器模式，我们刚刚的例子就是一个商业环境，而且现在模型运算的例子非常多，目前很多商业机构已经能够提供出大量的数据进行分析。

27.3.4 解释器模式的注意事项

      尽量不要在重要的模块中使用解释器模式，否则维护会是一个很大的问题。在项目中可以使用shell、JRuby、Groovy等脚本语言来代替解释器模式，弥补Java编译型语言的不足。我们在一个银行的分析型项目中就采用JRuby进行运算处理，避免使用解释器模式的四则运算，效率和性能各方面表现良好。

27.4 最佳实践

      解释器模式在实际的系统开发中使用的非常少，因为它会引起效率、性能以及维护等问题，一般在大中型的框架型项目能够找到它的身影，比如一些数据分析工具、报表设计工具、科学计算工具等等，若你确实遇到“一种特定类型的问题发生的频率足够高”的情况，准备使用解释器模式时，可以考虑一下Expression4J、MESP（Math Expression String Parser）、Jep等开源的解析工具包（这三个开源产品都可以百度、Google中搜索到，请读者自行查询），功能都异常强大，而且非常容易使用，效率也还不错，实现大多数的数学运算完全没有问题，自己没有必要从头开始编写解释器，有人已经建立了一条康庄大道，何必再走自己的泥泞小路呢？