【设计模式】 解释器模式

时间：2021-07-27 17:11:41

1、定义

1.1 标准定义

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

1.2 通用类图

【设计模式】 解释器模式

● AbstractExpression——抽象解释器
具体的解释任务由各个实现类完成， 具体的解释器分别由TerminalExpression和NonterminalExpression完成。
● TerminalExpression——终结符表达式
实现与文法中的元素相关联的解释操作， 通常一个解释器模式中只有一个终结符表达式， 但有多个实例， 对应不同的终结符。 具体到我们例子就是VarExpression类， 表达式中的每个终结符都在栈中产生了一个VarExpression对象。
● NonterminalExpression——非终结符表达式
文法中的每条规则对应于一个非终结表达式， 具体到我们的例子就是加减法规则分别对应到AddExpression和SubExpression两个类。 非终结符表达式根据逻辑的复杂程度而增加， 原则上每个文法规则都对应一个非终结符表达式。
● Context——环境角色
一般为表达式容器。

2、实现

2.1 类图

【设计模式】 解释器模式

AbstractExpression抽象解释器，具体的解释任务由各个实现类完成，具体的解释器分别由TerminalExpression和NonterminalExpression完成。抽象表达式是生成语法集合（ 也叫做语法树） 的关键， 每个语法集合完成指定语法解析
任务， 它是通过递归调用的方式， 最终由最小的语法单元进行解析完成。 

TerminalExpression终结符表达式，实现与文法中的元素相关的解释操作，通常一个解释器模式中只能有一个终结符表达式。

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

Context环境角色。

2.2 代码

#pragma once
#include<stack>
#include<iostream>
using namespace std;
class Object;
class Context;
//抽象表达式

//抽象表达式是生成语法集合/语法树的关键，每个语法集合完成指定语法解析任务，通过递归调用方式完成
class Expression
{
public:
virtual Object* interpreter(Context *ctx) = 0
    {
        cout << "If you Can, you Don't" << endl;
return NULL;
    };
};
//终结符表达式简单，主要处理场景元素和数据的转换
//终结符表达式
class TerminalExpression :public Expression
{
    Object* interpreter(Context*ctx)
    {
        cout << "TerminalExpression::interpreter" << endl;
return NULL;
    }
};

//每个非终结符表达式都表示一个文法规则，每个文法规则又只关心周边文法规则的结果，所以就会有递归调用而存在
//非终结符表达式
class NonterminalExpression :public Expression
{
public:
    NonterminalExpression(Expression* x1, ...)
    {
for (int i = 0; i < 4; ++i)
        {
            _st.push(x1);
        }
    }
    Object *interpreter(Context*ctx)
    {
//核心支出在于这里。。进行文法处理，并且产生递归调用
//if(typeid().name() != "TerminalExpression")
//递归调用
//文法处理
while (!_st.empty())
        {
            Expression* tp = _st.top();
            _st.pop();
            cout << "NoterminalExpression::interpreter" << endl;
            tp->interpreter(ctx);
        }
return NULL;
    }
private:
    stack <Expression*> _st;
};
class Context{
};

class Client
{
public:
void operator()()
    {
        Context *ctx = new Context();
        stack<Expression*> st;
for (int i = 0; i < 5; ++i)
        {
//进行语法判断，并且产生递归调用
            st.push(new TerminalExpression());
            st.push(new NonterminalExpression(new TerminalExpression()));
        }
//产生一个完整的语法树，由各个具体的语法分析进行解析
        Expression *exp = st.top();
        exp->interpreter(ctx);
    }
};

 

3、总结

3.1 优点

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

3.2 缺点

● 解释器模式会引起类膨胀
每个语法都要产生一个非终结符表达式， 语法规则比较复杂时， 就可能产生大量的类文件， 为维护带来了非常多的麻烦。
● 解释器模式采用递归调用方法
每个非终结符表达式只关心与自己有关的表达式， 每个表达式需要知道最终的结果， 必须一层一层地剥茧， 无论是面向过程的语言还是面向对象的语言， 递归都是在必要条件下使用的， 它导致调试非常复杂。 想想看， 如果要排查一个语法错误， 我们是不是要一个断点一个断点地调试下去， 直到最小的语法单元。
● 效率问题
解释器模式由于使用了大量的循环和递归， 效率是一个不容忽视的问题， 特别是一用于解析复杂、 冗长的语法时， 效率是难以忍受的。

3.3 使用场景

● 重复发生的问题可以使用解释器模式
例如， 多个应用服务器， 每天产生大量的日志， 需要对日志文件进行分析处理， 由于各个服务器的日志格式不同， 但是数据要素是相同的， 按照解释器的说法就是终结符表达式都是相同的， 但是非终结符表达式就需要制定了。 在这种情况下， 可以通过程序来一劳永逸地解决该问题。
● 一个简单语法需要解释的场景
为什么是简单？ 看看非终结表达式， 文法规则越多， 复杂度越高， 而且类间还要进行递归调用（ 看看我们例子中的栈）。想想看，多个类之间的调用你需要什么样的耐心和信心去排查问题。因此，解释器模式一般用来解析比较标准的字符集，例如SQL语法分析， 不过该部分逐渐被专用工具所取代 。

 

标签：

相关文章