解释器模式 深度解析(2)

上一章已经初步介绍了解释器模式

这一章将 通过模式的 适用环境 ,解决方案,解决问题 ,模式应用来进一步介绍解释其模式

模式定义:

解释器模式(Interpreter Pattern) :定义语言的文法,并且建立一个解释器来解释该语言中的句子,这里的“语言”意思是使用规定格式和语法的代码,它是一种类行为型模式。

适用环境:

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

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

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

文法较为简单。

效率不是关键问题。

一些重复发生的事情包含固定的一系列操作类型,比较适合用解释器模式来实现。如果一种特定类型的问题发生的频率足够高,那么可能就值得将该问题的各个实例表述为一个简单语言中的句子.这样就可以构建一个解释器,该解释器通过解释这些句子来解决该问题.

模式结构

模式结构

解释器模式包含如下角色:

Abstract Expression: 抽象表达式

Terminal Expression: 终结符表达式

Nonterminal Expression: 非终结符表达式

Context: 环境类

Client: 客户类

模式分析

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

解决问题:

比如加减乘除四则运算,但是公式每次都不同,比如可配置,有时是a + b - c x d,有时是a x b + c - d,等等个,公式千变万化,但是都是由加减乘除四个非终结符来连接的,这时我们就可以使用解释器模式。

解决方案:

文法规则

文法规则实例:

expression ::= value | symbol

symbol ::= expression ‘+‘ expression | expression ‘-‘ expression

value ::= an integer //一个整数值

在文法规则定义中可以使用一些符号来表示不同的含义,如使用“|”表示或,使用“{”和“}”表示组合,使用“*”表示出现0次或多次等,其中使用频率最高的符号是表示或关系的“|” 。

抽象语法树:

除了使用文法规则来定义一个语言,在解释器模式中还可以通过一种称之为抽象语法树(Abstract Syntax Tree, AST)的图形方式来直观地表示语言的构成,每一棵抽象语法树对应一个语言实例。

模式分析

抽象语法树描述了如何构成一个复杂的句子,通过对抽象语法树的分析,可以识别出语言中的终结符和非终结符类。

在解释器模式中,每一种终结符和非终结符都有一个具体类与之对应,正因为使用类来表示每一个语法规则,使得系统具有较好的扩展性和灵活性。

模式优缺点

解释器模式的优点

易于改变和扩展文法。

易于实现文法。

增加了新的解释表达式的方式。

解释器模式的缺点

对于复杂文法难以维护。

执行效率较低。

应用场景很有限。

模式应用

(1) 解释器模式在使用面向对象语言实现的编译器中得到了广泛的应用,如Smalltalk语言的编译器。

(2) 目前有一些基于Java抽象语法树的源代码处理工具,如在Eclipse中就提供了Eclipse AST,它是Eclipse JDT的一个重要组成部分,用来表示Java语言的语法结构,用户可以通过扩展其功能,创建自己的文法规则。

(3) 可以使用解释器模式,通过C++、Java、C#等面向对象语言开发简单的编译器,如数学表达式解析器、正则表达式解析器等,用于增强这些语言的功能,使之增加一些新的文法规则,用于解释一些特定类型的语句。

原文地址:https://www.cnblogs.com/du1269038969/p/9096869.html

时间: 2024-11-05 18:47:38

解释器模式 深度解析(2)的相关文章

模板方法模式深度解析(一)

1. 概述 定义一个操作中的算法的骨架,而将步骤延迟到子类中.模板方法使得子类可以不改变一个算法的结构即可重定义算法的某些特定步骤. 2. 模式中的角色 2.1 抽象类(AbstractClass):实现了模板方法,定义了算法的骨架. 2.2 具体类(ConcreteClass):实现抽象类中的抽象方法,已完成完整的算法. 3. 模式解读 3.1 模板方法类图 3.2 模板方法模式代码实现 /// <summary> /// 抽象类 /// </summary> public ab

[工作中的设计模式]解释器模式模式Interpreter

一.模式解析 解释器模式是类的行为模式.给定一个语言之后,解释器模式可以定义出其文法的一种表示,并同时提供一个解释器.客户端可以使用这个解释器来解释这个语言中的句子. 以上是解释器模式的类图,事实上我很少附上类图,但解释器模式确实比较抽象,为了便于理解还是放了上来,此模式的要点是: 1.客户端提供一个文本.表达式或者其他,约定解析格式 2.针对文本中可以分为终结符表达式和非终结符表达式, 3.终结符表达式无需进一步解析,但仍需要转化为抽象接口的实例 4.针对非终结表达式,没一种标示需要定义一种解

Java解释器模式`

解释器模式提供了一种评估计算语言语法或表达式的方法. 这种类型的模式属于行为模式. 这种模式涉及实现一个表达式接口,它告诉解释一个指定的上下文. 此模式用于SQL解析,符号处理引擎等. 实现示例 我们将创建一个接口Expression并且在具体的类实现这个Expression接口. 定义了一个TerminalExpression类,用作所讨论的上下文的主解释器. 其他的类 - OrExpression和AndExpression用于创建组合表达式. InterpreterPatternDemo这

《JAVA与模式》之解释器模式

解释器模式是类的行为模式.给定一个语言之后,解释器模式可以定义出其文法的一种表示,并同时提供一个解释器.客户端可以使用这个解释器来解释这个语言中的句子. 解释器模式的结构 下面就以一个示意性的系统为例,讨论解释器模式的结构.系统的结构图如下所示: 模式所涉及的角色如下所示: (1)抽象表达式(Expression)角色:声明一个所有的具体表达式角色都需要实现的抽象接口.这个接口主要是一个interpret()方法,称做解释操作. (2)终结符表达式(Terminal Expression)角色:

解释器模式(Interpreter Pattern)

解释器模式:为语言创建解释器,提供评估语言的语法或表达式的方法. 例子: public interface Expression { public abstract boolean interpret(String context); } public class TerminalExpression implements Expression { private String data; public TerminalExpression(String data) { this.data =

第17章 行为型模式—解释器模式

1. 解释器模式(Interpreter Pattern)的定义 (1)定义 给定一个语言,定义它的文法的一种表示,并定义一个解释器,这个解释器使用该表示来解释语言中的句子. ①文法:即语法规则.在解释器模式中每一个语法都将对应一个解释器对象,用来处理相应的语法规则.它对于扩展.改变文法以及增加新的文法规则都很方便. ②解释器模式描述了如何为简单的语言定义一个文法,如何在该语言中表示一个句子,以及如何解释这些句子. ③在解释器模式中可以通过一种称之为抽象语法树(Abstract Syntax T

原始的解释器模式(Interpreter Pattern)

解释器模式的定义(现实项目中很少遇到,因此直接理论先...) 解释器模式是一种按照规定语法进行解析的方案,在现在项目中使用较少,其定义为:给定一门语言,定义它的方法的一种表示,并定义一个解释器,该解释器使用该表示来解释语言中的句子.其构成如下: 1.AbstractExpression--抽象解释器 具体的解释任务由各个实现类完成,具体的解释器分别由TerminalExpression和NonterminalExpression完成 2.TerminalExpression--终结符表达式 实现

Kafka深度解析

Kafka深度解析 原创文章,转载请务必将下面这段话置于文章开头处(保留超链接).本文转发自Jason's Blog,原文链接 http://www.jasongj.com/2015/01/02/Kafka深度解析 背景介绍 Kafka简介 Kafka是一种分布式的,基于发布/订阅的消息系统.主要设计目标如下: 以时间复杂度为O(1)的方式提供消息持久化能力,即使对TB级以上数据也能保证常数时间的访问性能 高吞吐率.即使在非常廉价的商用机器上也能做到单机支持每秒100K条消息的传输 支持Kafk

解释器模式——HeadFirst设计模式学习笔记

解释器模式:给定一种语言,定义他的文法的一种表示,并定义一个解释器,该解释器使用该表示来解释语言中句子 特点: 每一种语法设置为一个类,便于实现 便于扩展语言的语法 用与处理重复发生的交叉问题或解析一种语言 缺点: 解释器模式会引起类膨胀 效率不高 解释器模式采用递归调用方法 举例: 1 //解释器接口 2 public interface Expression { 3 public boolean interpret(String context); 4 } 5 6 //实现Or解释器 7 p