【设计模式】 解释器模式

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——抽象解释器
  具体的解释任务由各个实现类完成, 具体的解释器分别由TerminalExpressionNonterminalExpression完成。

  ● TerminalExpression——终结符表达式
  实现与文法中的元素相关联的解释操作, 通常一个解释器模式中只有一个终结符表达式, 但有多个实例, 对应不同的终结符。 具体到我们例子就是VarExpression类, 表达式中的每个终结符都在栈中产生了一个VarExpression对象。

  ● NonterminalExpression——非终结符表达式
  文法中的每条规则对应于一个非终结表达式, 具体到我们的例子就是加减法规则分别对应到AddExpressionSubExpression两个类。 非终结符表达式根据逻辑的复杂程度而增加, 原则上每个文法规则都对应一个非终结符表达式。

  ● Context——环境角色
  一般为表达式容器。

2、实现

2.1 类图

【设计模式】 解释器模式

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

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

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

  Context环境角色。

2.2 代码

// InterpreterPattern.cpp : 定义控制台应用程序的入口点。  
//  
  
#include "stdafx.h"  
#include <iostream>    
#include <map>    
#include <string>    

using namespace std;  

class Context  
{  
private:  
    map<string, int> valueMap;  

public:  
    void addValue(string key, int value)  
    {  
        valueMap.insert(std::pair<string, int>(key, value));  
    }  

    int getValue(string key)  
    {  
        return valueMap[key];  
    }  
};  

class AbstractExpression  
{  
public:  
    virtual int interpreter(Context context) = 0;  
};  

class AddNonterminalExpression : public AbstractExpression  
{  
private:  
    AbstractExpression *left;  
    AbstractExpression *right;  

public:  
    AddNonterminalExpression(AbstractExpression *left, AbstractExpression *right)  
    {  
        this->left = left;  
        this->right = right;  
    }  

    int interpreter(Context context)  
    {  
        return this->left->interpreter(context) + this->right->interpreter(context);  
    }  

};  

class SubtractNonterminalExpression : public AbstractExpression  
{  
private:  
    AbstractExpression *left;  
    AbstractExpression *right;  

public:  
    SubtractNonterminalExpression(AbstractExpression *left, AbstractExpression *right)  
    {  
        this->left = left;  
        this->right = right;  
    }  

    int interpreter(Context context)  
    {  
        return this->left->interpreter(context) - this->right->interpreter(context);  
    }  

};  

class TerminalExpression : public AbstractExpression  
{  
private:  
    int i;  

public:  
    TerminalExpression(int i)  
    {  
        this->i = i;  
    }  

    int interpreter(Context context)  
    {  
        return this->i;  
    }  
};  

int main() {  
    //a-b+c  
    Context context;  
    context.addValue("a", 7);  
    context.addValue("b", 8);  
    context.addValue("c", 2);  

    SubtractNonterminalExpression *subtractValue = new SubtractNonterminalExpression(new TerminalExpression(  
        context.getValue("a")), new TerminalExpression(context.getValue("b")));  

    AddNonterminalExpression *addValue = new AddNonterminalExpression(subtractValue, new TerminalExpression(  
        context.getValue("c")));  

    cout << addValue->interpreter(context)<<endl;  

    return 0;  
}  

3、总结

3.1 优点

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

3.2 缺点

  ● 解释器模式会引起类膨胀
  每个语法都要产生一个非终结符表达式, 语法规则比较复杂时, 就可能产生大量的类文件, 为维护带来了非常多的麻烦。

  ● 解释器模式采用递归调用方法
  每个非终结符表达式只关心与自己有关的表达式, 每个表达式需要知道最终的结果, 必须一层一层地剥茧, 无论是面向过程的语言还是面向对象的语言, 递归都是在必要条件下使用的, 它导致调试非常复杂。 想想看, 如果要排查一个语法错误, 我们是不是要一个断点一个断点地调试下去, 直到最小的语法单元。

  ● 效率问题
  解释器模式由于使用了大量的循环和递归, 效率是一个不容忽视的问题, 特别是一用于解析复杂、 冗长的语法时, 效率是难以忍受的。

3.3 使用场景

  ● 重复发生的问题可以使用解释器模式
  例如, 多个应用服务器, 每天产生大量的日志, 需要对日志文件进行分析处理, 由于各个服务器的日志格式不同, 但是数据要素是相同的, 按照解释器的说法就是终结符表达式都是相同的, 但是非终结符表达式就需要制定了。 在这种情况下, 可以通过程序来一劳永逸地解决该问题。

  ● 一个简单语法需要解释的场景
  为什么是简单? 看看非终结表达式, 文法规则越多, 复杂度越高, 而且类间还要进行递归调用( 看看我们例子中的栈)。想想看,多个类之间的调用你需要什么样的耐心和信心去排查问题。因此,解释器模式一般用来解析比较标准的字符集,例如SQL语法分析, 不过该部分逐渐被专用工具所取代 。

原文链接: https://www.cnblogs.com/ChinaHook/p/7309323.html

欢迎关注

微信关注下方公众号,第一时间获取干货硬货;公众号内回复【pdf】免费获取数百本计算机经典书籍;

也有高质量的技术群,里面有嵌入式、搜广推等BAT大佬

    【设计模式】 解释器模式

原创文章受到原创版权保护。转载请注明出处:https://www.ccppcoding.com/archives/399508

非原创文章文中已经注明原地址,如有侵权,联系删除

关注公众号【高性能架构探索】,第一时间获取最新文章

转载文章受原作者版权保护。转载请注明原作者出处!

(0)
上一篇 2023年4月13日 上午9:24
下一篇 2023年4月13日 上午9:24

相关推荐