博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
设计模式22---设计模式之解释器模式(Interpreter)(行为型)
阅读量:7051 次
发布时间:2019-06-28

本文共 2044 字,大约阅读时间需要 6 分钟。

1.讲解解释器模式

1.1解释器模式定义

给定一个语言,定义它的文法的一种表示,并定义一个解释器,这个解释器使用该表示来解释语言中的句子。

1.2解释器模式要点

解析器:把描述客户端调用要求的表达式,经过解析,形成一个抽象语法树的程序。

解释器:解释语法抽象树
一般一个解释器处理一个语法规则

1.3解释器模式的结构图以及说明

 

抽象解释器:声明一个所有具体表达式都要实现的抽象接口(或者抽象类),接口中主要是一个interpret()方法,称为解释操作。具体解释任务由它的各个实现类来完成,具体的解释器分别由终结符解释器TerminalExpression和非终结符解释器NonterminalExpression完成。
终结符表达式:实现与文法中的元素相关联的解释操作,通常一个解释器模式中只有一个终结符表达式,但有多个实例,对应不同的终结符。终结符一半是文法中的运算单元,比如有一个简单的公式R=R1+R2,在里面R1和R2就是终结符,对应的解析R1和R2的解释器就是终结符表达式。                                
非终结符表达式:文法中的每条规则对应于一个非终结符表达式,非终结符表达式一般是文法中的运算符或者其他关键字,比如公式R=R1+R2中,+就是非终结符,解析+的解释器就是一个非终结符表达式。非终结符表达式根据逻辑的复杂程度而增加,原则上每个文法规则都对应一个非终结符表达式。
环境角色:这个角色的任务一般是用来存放文法中各个终结符所对应的具体值,比如R=R1+R2,我们给R1赋值100,给R2赋值200。这些信息需要存放到环境角色中,很多情况下我们使用Map来充当环境角色就足够了

1.4解释器模式的示例代码

package demo20.interpreter.example2;/** * 抽象表达式 */public abstract class AbstractExpression {	/**	 * 解释的操作	 * @param ctx 上下文对象	 */	public abstract void interpret(Context ctx);}***************************************************************************************************package demo20.interpreter.example2;/** * 终结符表达式 */public class TerminalExpression extends AbstractExpression{		public void interpret(Context ctx) {		//实现与语法规则中的终结符相关联的解释操作	}}*************************************************************************************************package demo20.interpreter.example2;/** * 非终结符表达式 */public class NonterminalExpression extends AbstractExpression {	public void interpret(Context ctx) {		// 实现与语法规则中的非终结符相关联的解释操作	}}*************************************************************************************************package demo20.interpreter.example2;/** * 上下文,包换解释器之外的一些全局信息 */public class Context {}*************************************************************************************************package demo20.interpreter.example2;/** * 使用解释器的客户 */public class Client {	//主要按照语法规则对特定的句子构建抽象语法树	//然后调用解释操作}

1.5解释器模式的本质

分离实现,解释执行

1.6解释器模式的优缺点

优点:易于实现算法,易于扩展新的语法

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

1.7何时选用

当有一个语言需要解释执行,并且可以将该语言中的句子表示为一个抽象的语法树的时候

语法相对比较简单
效率要求不高

1.8附注

由于解释器应用的情况比较少,所以这里就不举例子了。

你可能感兴趣的文章
关于性能优化的那点事——函数节流
查看>>
NPM简单入门
查看>>
Linux Namespace系列(05):pid namespace (CLONE_NEWPID)
查看>>
爬虫学习之基于Scrapy的网络爬虫
查看>>
基于 WebSocket 实现 WebGL 3D 拓扑图实时数据通讯同步(一)
查看>>
Docker利用Jexus独立版部署MVC Demo
查看>>
199. Binary Tree Right Side View
查看>>
ERR_INCOMPLETE_CHUNKED_ENCODING
查看>>
ReactiveCocoa与swift
查看>>
欧洲杯激战正酣,如何用大数据变身专家级球迷
查看>>
[LintCode] Longest Increasing Subsequence
查看>>
Best Time to Buy and Sell Stock(121)
查看>>
spring ApplicationListener&ApplicationEvent
查看>>
Design Pattern - Abstract Factory Pattern(译)
查看>>
Compass排版模块
查看>>
RD为什么也需要云
查看>>
运行 Docker 容器时的安全风险:别丢了你的套接字
查看>>
Laravel 添加自定义辅助函数
查看>>
【JVM类加载机制】从一个对象的验证问题说开去
查看>>
django 1.8 官方文档翻译:13-1-2 使用Django认证系统
查看>>