设计模式之解释器模式

解释器模式的概念

给定一个语言,定义它的文法的一种表示,并定义一个解释器,这个解释器使用该表示来解释语言中的句子。

这是23种设计模式中最后一种了,它是一种不太常用的设计模式,不过还是要学习的。

举个栗子

解释器模式的模型图

解释器模式里面有四种角色:抽象解释器,终结符表达式,非终结符表达式,环境角色。

  • 抽象表达式
1
2
3
4
public abstract class Expression {
//解析任务
public abstract Object interpret(Context context);
}
  • 终结符表达式
1
2
3
4
5
6
7
public class TerminalExpression extends Expression {
//终结符表达式通常只有一个
@Override
public Object interpret(Context context) {
return null;
}
}
  • 非终结符表达式
1
2
3
4
5
6
7
8
9
10
public class NonterminalExpression extends Expression {
//非终结符表达式会依赖其他表达式
public NonterminalExpression(Exception... exceptions){
}
@Override
public Object interpret(Context context) {
//进行文法处理
return null;
}
}
  • 调用场景
1
2
3
4
5
6
7
8
9
10
11
12
13
14
public class Client {
public static void main(String[] args) {
Context context = new Context();
//容器
Stack<Expression> stack;
for (; ; ) {
//语法判断,递归调用
}
//分析语法
Expression expression=stack.pop();
//进入场景
expression.interpret(context);
}
}

环境未列出,因为实际开发中可以采用HashMap代替,解释器模式封装了一个语法规范文件,避免了调用者和语法解析器之间产生耦合,在解释器模式中可以通过一种称之为抽象语法树的图形方式来直观地表示语言的构成,每一棵抽象语法树对应一个语言实例。

适用范围

解释器模式适用与解决重复发生的解释语法的问题问,面对系统化的语法结构,恰当使用可以使工作大量简化。

优点缺点

优点是扩展方便,调整表达式结构就可以实现语法的修改。

缺点一方面是类太多会造成类膨胀,另一方面就是内部的大量递归会严重影响性能。

注意事项

尽量不要使用解释器模式处理重要的业务,解释器模式会带来很多维护性的问题,在实际应用中可以使用脚本语言来代替解释器模式。


写在后面的话

到此为止,设计模式的系列文章就要结束了,这里面说的设计模式是狭义上的,由GoF提出的23种设计模式,现在可能还有新的设计模式产生,在此不做讨论。这些设计模式在实际项目中当然不能独立存在,具体的组合应用要依场景而定,在这里只是系统的看了一遍这些基本概念,开发的路还很长,随着接触工程量的增加,对设计模式会有更深刻的了解。至此,本系列全部文章结束。

-------------本文结束感谢您的阅读-------------
坚持原创技术分享,您的支持将鼓励我继续创作!