架构模式——解释器模式

什么是架构模式？

根据维基百科中的定义：

架构模式是一个通用的、可重用的解决方案，用于在给定上下文中的软件体系结构中常常出现的问题。架构模式与软件设计模式相似，但具备更普遍的范围。

 

1、模式定义

解释器模式用于设计一个解释用专用语言编写的程序的组件。它主要指定如何评估程序的行数，即以特定的语言编写的句子或表达式。其基本思想是为每种语言的符号都有一个分类。

 

2、模式结构

上图是解释器模式的UML结构图

解释器模式主要包含以下几个角色：

• AbstractExpression: 抽象表达式。声明一个抽象的解释操做，该接口为抽象语法树中全部的节点共享。
• TerminalExpression: 终结符表达式。实现与文法中的终结符相关的解释操做。实现抽象表达式中所要求的方法。文法中每个终结符都有一个具体的终结表达式与之相对应。
• NonterminalExpression: 非终结符表达式。为文法中的非终结符相关的解释操做。
• Context: 环境类。包含解释器以外的一些全局信息。
• Client: 客户类。

3、代码实现

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);
    }
}

　　文法递归的代码部分须要根据具体的状况来实现，所以在代码中没有体现。抽象表达式是生成语法集合的关键，每一个非终结符表达式解释一个最小的语法单元，而后经过递归的方式将这些语法单元组合成完整的文法，这就是解释器模式。

4、优缺点

　　优势：高度动态的行为是可行的。对终端用户编程性提供好处。提升灵活性，由于替换一个解释程序很容易。

　　缺点：因为解释语言一般比编译后的语言慢，所以性能多是一个问题。

5、使用场景

• 有一个简单的语法规则，好比一个sql语句，若是咱们须要根据sql语句进行rm转换，就可使用解释器模式来对语句进行解释。
• 一些重复发生的问题，好比加减乘除四则运算，可是公式每次都不一样，有时是a+b-c*d，有时是a*b+c-d，等等等等个，公式变幻无穷，可是都是由加减乘除四个非终结符来链接的，这时咱们就可使用解释器模式。

6、模式总结

　　注意事项

　　解释器模式真的是一个比较少用的模式，由于对它的维护实在是太麻烦了，想象一下，一坨一坨的非终结符解释器，假如不是事先对文法的规则了如指掌，或者是文法特别简单，则很难读懂它的逻辑。解释器模式在实际的系统开发中使用的不多，由于他会引发效率、性能以及维护等问题。

 

一、在解释器模式中因为语法是由不少类表示的，因此可扩展性强。

二、虽然解释器的可扩展性强，可是若是语法规则的数目太大的时候，该模式可能就会变得异常复杂。因此解释器模式适用于文法较为简单的。

三、解释器模式能够处理脚本语言和编程语言。经常使用于解决某一特定类型的问题频繁发生状况。

 

PS：该博客因为我理解有限，不少是查找相关资料，望谅解。。。