什么是架构模式？
根据维基百科中的定义：
架构模式是一个通用的、可重用的解决方案，用于在给定上下文中的软件体系结构中经常出现的问题。架构模式与软件设计模式类似，但具有更广泛的范围。
一、模式定义
解释器模式用于设计一个解释用专用语言编写的程序的组件。它主要指定如何评估程序的行数，即以特定的语言编写的句子或表达式。其基本思想是为每种语言的符号都有一个分类。
二、模式结构
上图是解释器模式的UML结构图
解释器模式主要包含如下几个角色：
- AbstractExpression: 抽象表达式。声明一个抽象的解释操作，该接口为抽象语法树中所有的节点共享。
- TerminalExpression: 终结符表达式。实现与文法中的终结符相关的解释操作。实现抽象表达式中所要求的方法。文法中每一个终结符都有一个具体的终结表达式与之相对应。
- NonterminalExpression: 非终结符表达式。为文法中的非终结符相关的解释操作。
- Context: 环境类。包含解释器之外的一些全局信息。
- Client: 客户类。
三、代码实现
class Context {}
abstract class Expression {
public abstract Object interpreter(Context ctx);
}
class TerminalExpression extends Expression {
public Object interpreter(Context ctx){
return null;
}
}
class NonterminalExpression extends Expression {
public NonterminalExpression(Expression...expressions){
}
public Object interpreter(Context ctx){
return null;
}
}
public class Client {
public static void main(String[] args){
String expression = "";
char[] charArray = expression.toCharArray();
Context ctx = new Context();
Stack<Expression> stack = new Stack<Expression>();
for(int i=0;i<charArray.length;i++){
//进行语法判断，递归调用
}
Expression exp = stack.pop();
exp.interpreter(ctx);
}
}
文法递归的代码部分需要根据具体的情况来实现，因此在代码中没有体现。抽象表达式是生成语法集合的关键，每个非终结符表达式解释一个最小的语法单元，然后通过递归的方式将这些语法单元组合成完整的文法，这就是解释器模式。
四、优缺点
优点：高度动态的行为是可行的。对终端用户编程性提供好处。提高灵活性，因为替换一个解释程序很容易。
缺点：由于解释语言通常比编译后的语言慢，因此性能可能是一个问题。
五、使用场景
- 有一个简单的语法规则，比如一个sql语句，如果我们需要根据sql语句进行rm转换，就可以使用解释器模式来对语句进行解释。
- 一些重复发生的问题，比如加减乘除四则运算，但是公式每次都不同，有时是a+b-c*d，有时是a*b+c-d，等等等等个，公式千变万化，但是都是由加减乘除四个非终结符来连接的，这时我们就可以使用解释器模式。
六、模式总结
注意事项
解释器模式真的是一个比较少用的模式，因为对它的维护实在是太麻烦了，想象一下，一坨一坨的非终结符解释器，假如不是事先对文法的规则了如指掌，或者是文法特别简单，则很难读懂它的逻辑。解释器模式在实际的系统开发中使用的很少，因为他会引起效率、性能以及维护等问题。
1、在解释器模式中由于语法是由很多类表示的，所以可扩展性强。
2、虽然解释器的可扩展性强，但是如果语法规则的数目太大的时候，该模式可能就会变得异常复杂。所以解释器模式适用于文法较为简单的。
3、解释器模式可以处理脚本语言和编程语言。常用于解决某一特定类型的问题频繁发生情况。
PS：该博客由于我理解有限，很多是查找相关资料，望谅解。。。