1. 解释器模式的概念
解释器模式(interpreter),给定一个语言,定义它的文法的一种表示,并定义一个解释器,这个解释器使用该表示来解释语言中的句子。
解释器模式需要解决的是,如果一种特定类型的问题发生的频率足够高,那么可能就值得将该问题的各个实例表述为一个简单语言中的句子。这样就可以构建一个解释器,该解释器通过解释这些句子来解决各种问题。
举个例子,正则表达式就是解释器模式的一种运用,在没有出现正则表达式之前,我们在 Email、电话这些场景中需要去判断字符串是否合法,我们会分别对他们编写特定的函数,这样的话Email一套、电话一套、账号一套、密码一套…
如果我要匹配的字符串特别多,这样做未免太过耗时费力,那如何将他们全部统一起来呢?那就是写一种无论在什么情况,只要我们规定好字符串规则,它就能进行匹配判断的表达式,正则表达式就这样发明出来了。而解释器模式就是为正则表达式定义了一个文法,如何表示一个特定的正则表达式,以及如何去解释这个正则表达式。
再举个例子,JVM的跨平台性,为什么同一套Java代码,在Window上、Linux上、MAC等平台都能被编译运行呢?这是因为Java编译器会将java文件编译成字节码文件,.class
文件可以被JVM识别并执行,JVM就会将其转换成操作系统识别的机器码。
所以无论在什么平台上,JVM只认 .class
文件。
其次,就算使用的不是Java语言,比如Python、JS,只要你的代码能被编译器编译成 .class
文件,Java虚拟机就能解释运行。
在这里面JVM就是提供了解释器的功能,它在向操作系统解释程序员写的代码。
2. UML图
AbstractExpression
抽象表达式
声明一个抽象的解释操作父类,并定义一个抽象的解释方法,其具体的实现在各个具体的子类解释器中完成TerminalExpression
终结符表达式
实现文法中与终结符有关的解释操作。文法中每一个终结符都有一个具体的终结表达式与之对应NonterminalExpression
非终结表达式
实现文法中与非终结符有关的解释操作Context
上下文环境
3. 实现一个简单的解释器
我们来实现一个对算术表达式的解释,比如表达式“m+n+p
”,如果我们使用解释器模式对该表达式进行解释,那么代表数字m、n和p三个字母我们就可以看成是终结符号,而“+”这个算术运算符号则可当做是非终结符号。同样地,我们先创建一个抽象解释器表示数学运算:
public abstract class ArithmeticExpression{
/**
* 抽象的解释方法
* 具体的解析逻辑由具体的子类实现
*
* @return 解析得到具体的值
*/
public abstract int interpret();
}
在该抽象解释器的解释方法interpet中,我们没有像前面UML图那样使用一个Context对象作为Iinterpret方法的返回类型,在本例中运算的结果都是作为参数返回,因此,没有必要使用额外的对象存储信息。ArighmeticExpression
有两个直接子类 NumExpression
和 OperatorExpression
,其中 NumExpression用于对数字进行解释:
class NumExpression extends ArithmeticExpression{
private int num;
public NumExpression(int num) {
this.num = num;
}
@Override
public int interpret() {
return num;
}
}
代码很简单,逻辑也很明确,就不多说了,OperatorExpression依然是一个抽象类,其声明两个ArighmeticExpression类型的成员变量存储运算符号两边的数字解释器,这两个成员变量会在构造方法中被赋值。
public abstract class OperatorExpression extends ArithmeticExpression {
// 声明两个成员变量存储运算符号两边的数字解释器
protected ArithmeticExpression exp1,exp2;
public OperatorExpression(ArithmeticExpression exp1, ArithmeticExpression exp2) {
this.exp1 = exp1;
this.exp2 = exp2;
}
}
OperatorExpression也有一个直接子类 AdditionExpression
,就是用来对加法进行进行解释:
public abstract class OperatorExpression extends ArithmeticExpression {
// 声明两个成员变量存储运算符号两边的数字解释器
protected ArithmeticExpression exp1,exp2;
public OperatorExpression(ArithmeticExpression exp1, ArithmeticExpression exp2) {
this.exp1 = exp1;
this.exp2 = exp2;
}
}
上面就是本例中所要使用到的所有解释器。除此之外,我们创建一个Calculator类来处理一些相关的业务:
class Calculator {
// 声明一个Stack栈存储并操作所有相关的解释器
private Stack<ArithmeticExpression> mExpStack = new Stack<>();
public Calculator(String expression) {
// 声明两个ArithmeticExpression类型的临时变量,存储运算符左右两边的数字解释器
ArithmeticExpression exp1, exp2;
// 根据空格分割表达式字符串
String[] elements = expression.split(" ");
/**
* 循环遍历表达式元素数组
*/
for (int i = 0; i < elements.length; i++) {
/**
* 判断运算符号
*/
if (elements[i].charAt(0) == '+') {// 如果是加号,则将解释器弹出作为运算符号左边的解释器
exp1 = mExpStack.pop();
// 同时将运算符号数组下标下一个元素构造为一个数字解释器
exp2 = new NumExpression(Integer.parseInt(elements[++i]));
// 通过上面的两个数字解释器构造加法运算解释器
mExpStack.push(new AdditionExpression(exp1, exp2));
} else {// 如果为数字,则直接构造数字解释器并压入栈中
mExpStack.push(new NumExpression(Integer.parseInt(elements[i])));
}
}
}
/**
* 计算结果
*/
public int calculate() {
return mExpStack.pop().interpret();
}
}
这里需要注意的是,为了简化问题我们约定表达式字符串的每个元素必须使用空格间隔开,如“1 + 22 + 333 + 4444”这样的表达式是合法的,而“1+22+333+4444”则不合法,因此,我们才能在Calculator的构造方法中通过空格来拆分字符串。
Calculator类的逻辑很好理解,这里还是以“1 + 22 + 333 +4444”为例子,首先将其拆分成有7个元素组成的字符串数组,然后循环遍历,首先遍历到的元素为1,那么将其作为参数构造一个 NumExpression对象压入栈中,其次是加号运算符,此时我们将刚才压入栈的由元素1作为参数够着的NumExpression对象抛出作为加号运算符左边的数字数字解释器,将右边的数字(下标+1)作为右边的解释器。
最后通过左右两个数字解释器作为参数够着一个 AdditionExpression
加法解释器对象压入栈即可,这个过程其实就是在构建语法书,只不过我们将其单独的封装在了一个类里面而不是Client客户类进行,最后,我们公布一个 calculate方法执行解释并返回结果,调用 calculate方法输出结果即可。
最后是客户端类
public class Main {
public static void main(String[] args) {
Calculator c = new Calculator("123 + 4512 + 123911");
System.out.println(c.calculate());
}
}
上面我们只是简单地对加法运算定义了解释器,如果现在又想引入减法,就可以写一个类似加法的减法解释器即可,对拓展是保持开放的,但是需要修改 Calculate
类。
4. 小结
使用场景:
- 如果某个简单的语言需要解释执行而且可以将语言中的语句表示为一个抽象语法树时,可以考虑使用解释器模式
- 在某些特定的领域出现不断重复的问题时,可以将该领域的问题转化为一种语法规则下的语句,然后构建解释器来解释该语句
优点:最大的优点是其灵活的扩展性,当我们相对文法规则进行扩展时,只需要增加相应的非终结符解释器,并在构建抽象语法树时,使用到新增的解释器对象进行具体的解释即可,非常方便。
缺点:解释器模式的缺点也显而易见,因为对于每一条文法都可以对应至少一个解释器,其会生成大量的类,导致后期维护困难;同时,对于过于复杂的文法,构建起抽象语法树会显得异常繁琐,甚至有可能会出现需要构建多棵抽象语法树的情况,因此,对于复杂的文法并不推荐使用解释器模式。