Interpret 解释器模式

概述:

        未来机器智能化已然成为趋势,现在手机都能听懂英语和普通话,那我大中华几万种方言的被智能化也许也是趋势,我们的方言虽然和普通话相似,但是还是不一样的。这可能需要一个新的语法分析器来帮助我们。

我们的解释器模式就是描述了如何为简单的语言定义一个文法,如何在该语言中表示一个句子,以及如何解释这些句子。

但是解释一门自然语言是复杂的过程,我们以加减运算为例子来详细解释解释器模式。

类图和实例:

抽象表达式角色(AbstractExpression): 声明一个抽象的解释操作这个接口为所有具体表达式角色都要实现的
终结符表达式角色(TerminalExpression): 实现与文法中的元素相关联的解释操作通常一个解释器模式中只有一个终结符表达式但有多个实例对应不同的终结符
终结符就是语言中用到的基本元素一般不能再被分解: x -> xa, 这里a是终结符,因为没有别的规则可以把a变成别的符号,不过x可以变成别的符号,所以x是非终结符
非终结符表达式角色(NonterminalExpression): 文法中的每条规则对应于一个非终结表达式, 非终结表达式根据逻辑的复杂程度而增加原则上每个文法规则都对应一个非终结符表达式

环境角色(Context):包含解释器之外的一些全局信息

实例代码如下:

#include "stdafx.h"
#include <boost/make_shared.hpp>
#include <boost/shared_ptr.hpp>
#include <iostream>
#include <string>

using namespace boost;

class Context
{
};
//解释器抽象类
class AbstractExpression
{
public:
	virtual void Interpret(shared_ptr<Context> context) = 0;
};
//终结符表达式解释
class TerminalExpression : public AbstractExpression
{
public:
	std::string _m_statement;//需要解释的字符串
public:
	TerminalExpression(const std::string &str)
	{
		_m_statement = str;
	}

	TerminalExpression(){}

	void Interpret(shared_ptr<Context> context)
	{
		std::cout << _m_statement << ":TerminalExpression" << std::endl;
	}
};

//非终结符表达式解释
class NormalExpression : public AbstractExpression
{
public:
	NormalExpression(){}
	NormalExpression(shared_ptr<AbstractExpression> exp,int iTimes)
	{
		m_exp = exp;
		m_nTimes = iTimes;
	}
	void Interpret(shared_ptr<Context> context)
	{
		for(int i = 0; i < m_nTimes;++i)
		{
			m_exp->Interpret(context);
		}
	}
public:
	int m_nTimes;
	shared_ptr<AbstractExpression> m_exp;
};

void testInterpretMode()
{
	shared_ptr<Context> context = make_shared<Context>();
	shared_ptr<TerminalExpression> term = make_shared<TerminalExpression>("Hello");
	auto nor = make_shared<NormalExpression>(term,2);
	nor->Interpret(context);
}

适用性:

在以下情况下可以考虑使用解释器模式:

(1) 可以将一个需要解释执行的语言中的句子表示为一个抽象语法树。

(2)  一些重复出现的问题可以用一种简单的语言来进行表达。

(3) 一个语言的文法较为简单。

(4) 执行效率不是关键问题。(注:高效的解释器通常不是通过直接解释抽象语法树来实现的,而是需要将它们转换成其他形式,使用解释器模式的执行效率并不高。)

优缺点:

优点:

(1) 易于改变和扩展文法。由于在解释器模式中使用类来表示语言的文法规则,因此可以通过继承等机制来改变或扩展文法。

(2) 每一条文法规则都可以表示为一个类,因此可以方便地实现一个简单的语言。

(3) 实现文法较为容易。在抽象语法树中每一个表达式节点类的实现方式都是相似的,这些类的代码编写都不会特别复杂,还可以通过一些工具自动生成节点类代码。

(4) 增加新的解释表达式较为方便。如果用户需要增加新的解释表达式只需要对应增加一个新的终结符表达式或非终结符表达式类,原有表达式类代码无须修改,符合开闭原则

缺点:

(1) 对于复杂文法难以维护。在解释器模式中,每一条规则至少需要定义一个类,因此如果一个语言包含太多文法规则,类的个数将会急剧增加,导致系统难以管理和维护,此时可以考虑使用语法分析程序等方式来取代解释器模式。

(2) 执行效率较低。由于在解释器模式中使用了大量的循环和递归调用,因此在解释较为复杂的句子时其速度很慢,而且代码的调试过程也比较麻烦。

总论:

尽量不要在重要模块中使用解释器模式,因为维护困难。在项目中,可以使用脚本语言来代替解释器模式。


评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值