Atitit. 解释器模式框架选型 and应用场景attilax总结 oao

Atitit. 解释器模式框架选型 and应用场景attilax总结 oao

1. 解释器模式结构描述 1

2. 如何实现(简单的解释器模式,仅仅通过词法分析即可实现,而无需token流进行处理。 2

3. 单词流必须识别为保留字,标识符(变量),常量,操作符(运算符 )和界符五大类 2

3.1. 操作符(运算符 )::: 2

3.2. 4.界符:“;”分号,“{}”大括号,单引号,双引号
3

4. TerminalExpression和NonterminalExpression是两个实现。
3

5. 应用场景 3

5.1. 汉字转化为数字 3

5.2. Sql,hql,Criteria 转换hibernate 3

5.3. 表达式解析 4

5.4. 翻译词典 4

6. 解释器框架选型 4

1. 解释器模式结构描述

Context存储的全局上下文环境,AbstractExpression是所有表达式必须继承的接口,TerminalExpression和NonterminalExpression是两个实现。

除了上述用于表示表达式的类以外,通常在解释器模式中还提供了一个环境类Context,用于存储一些全局信息,通常在Context中包含了一个HashMap或ArrayList等类型的集合对象(也可以直接由HashMap等集合类充当环境类),存储一系列公共信息,如变量名与值的映射关系(key/value)等,用于在进行具体的解释操作时从中获取相关信息。其典型代码片段如下:


class Context {

private HashMap map = new HashMap();

public void assign(String key, String value) {

//往环境类中设值

}

public String  lookup(String key) {

//获取存储在环境类中的值

}

}

当系统无须提供全局公共信息时可以省略环境类,可根据实际情况决定是否需要环境类。

作者:: 老哇的爪子 Attilax 艾龙,  EMAIL:[email protected]

转载请注明来源: http://blog.csdn.net/attilax

2. 如何实现(简单的解释器模式,仅仅通过词法分析即可实现,而无需token流进行处理。

事实上,有些简单的解释器模式,仅仅通过词法分析即可实现,功能可以写在状态改变函数中,而无需对产生的token流进行处理。

3. 单词流必须识别为保留字,标识符(变量),常量,操作符(运算符 )和界符五大类

3.1. 操作符(运算符 ):::

() [] -> .


? :


条件


由右向左


() [] -> .


括号(函数等),数组,两种结构成员访问


由左向右


,


逗号(顺序)


+ -


加,减


由左向右

括号,纺括号,等号

参考

编译器DIY——词法分析 - GodLike - 博客频道 - CSDN.NET.htm

操作符要使用一个状态来描述的...

3.2. 4.界符:“;”分号,“{}”大括号,单引号,双引号

界符在处理的时候儿,林吧过滤...

4. TerminalExpression和NonterminalExpression是两个实现。

通常来说,操作符(运算符 )要使用NonterminalExpression来实现,建立一个class 来实现,

一个op一个class

5. 应用场景

5.1. 汉字转化为数字

的项目中,随着需要解析的汉字数据越来越大,需要解析方法能够随之处理更大级别的数据(万,亿…),通过扩展Express类,产生能够解析新增的级别的处理方法

5.2. Sql,hql,Criteria 转换hibernate

Criteria 2sql  可以使用hb的api

5.3. 表达式解析

5.4. 翻译词典

6.  解释器框架选型

6.0.1.1. 最佳实践

解释器模式在实际的系统开发中使用的非常少,因为它会引起效率、性能以及维护等问题,一般在大中型的框架型项目能够找到它的身影,比如一些数据分析工具、 报表设计工具、科学计算工具等等,若你确实遇到“一种特定类型的问题发生的频率足够高”的情况,准备使用解释器模式时,可以考虑一下 Expression4J、MESP(Math Expression String Parser)、Jep等开源的解析工具包(这三个开源产品都可以百度、Google中搜索到,请读者自行查询),功能都异常强大,而且非常容易使用,效 率也还不错,实现大多数的数学运算完全没有问题,自己没有必要从头开始编写解释器,有人已经建立了一条康庄大道,何必再走自己的泥泞小路呢?

Expression4J   百度28个

MESP  解释器   20个

参考

自定义语言的实现——解释器模式(三) - 刘伟技术博客 - 博客频道 - CSDN.NET.htm

时间: 2024-10-11 03:42:36

Atitit. 解释器模式框架选型 and应用场景attilax总结 oao的相关文章

atitit.自己动手开发编译器and解释器(2) ------语法分析,语义分析,代码生成--attilax总结

atitit.自己动手开发编译器and解释器(2) ------语法分析,语义分析,代码生成--attilax总结 1. 建立AST 抽象语法树 Abstract Syntax Tree,AST) 1 2. 建立AST 语法树----递归下降(recursive descent)法 2 3. 语法分析概念 2 3.1. 上下文无关语言,非终结符(nonterminal symbol),终结符(terminal symbol).注 2 3.2. 最左推导.当然也有最右推导 3 3.3. 分支预测的

atitit.html编辑器的设计要点与框架选型 attilax总结

atitit.html编辑器的设计要点与框架选型 attilax总结 1. html编辑器的设计要求1 1.1. 障碍访问 1 1.2. 强大Ajax上传 1 1.3. Word完美支持 2 1.4. 安全的UBB 2 1.5. 自动获取远程文件2 1.6. 文字水印/图片水印2 1.7. Word/Excel导入2 1.8. 强大表格处理功能2 1.9. 文件库2 1.10. 超强可视设置3 1.11. 国际化多语言支持3 1.12. 缩略图3 1.13. 支持WEBEQ公式编辑接口3 2. 

atitit.ajax 最佳实践跟框架选型 o99

atitit.ajax 最佳实践跟框架选型 1. 选型框架dwr/dwr3 跟jq 1 2. DWR方便的地方分为两个地方. 1 3. dwr 优点: 1 4. 缺点: 2 5. 根jq的区别 2 1. 选型框架dwr/dwr3 跟jq 2. DWR方便的地方分为两个地方. 前台: 1.前台的js方法的自动生成(由服务端自动发送js脚本到客户端), 用户无需关心,模拟后台的方法调用形式,上手容易. 后台 1.后台获取服务bean的plugin功能. (可以和Spring.Struts集成)提供服

atitit.软件开发--socket框架选型--netty vs mina j

atitit.软件开发--socket框架选型--netty vs mina j . Netty是由JBOSS提供的一个java开源框架 Apache mina 三.文档比较 mina文档多,,, 好几倍... 作者:: 老哇的爪子 Attilax 艾龙,  EMAIL:[email protected] 转载请注明来源: http://blog.csdn.net/attilax 四.UDP协议传输 1. netty将UDP无连接的特性暴露出来:而mina对UDP进行了高级层次的抽象,可以把UD

atitit. groupby linq的实现(1)-----linq框架选型 java .net php

atitit.  groupby linq的实现(1)-----linq框架选型 java .net php 实现方式有如下 1. Dsl/ Java8 Streams AP ,对象化的查询api ,推荐 1 2. Linq::: like  sql 的dsl 1 1.1. linq4j (jdk6 ok,jdk7 编译错误,又马jar下载) 1 1.2. Quaere:Java上的LINQ(新不上sourcecode) 1 1.3. joSQL也是与Quaere类似的API 2 1.4. .n

atitit.RESTful服务的概览and框架选型

1. REST基础概念: 1 2. URL说明: 1 3.  1 4. RESTful框架选型 2 1. spring mvc( recomm) 2 2. Jersey 2 5. 参考 3 1.  REST基础概念: · 在REST中的一切都被认为是一种资源. · 每个资源由URI标识. · 使用统一的接口.处理资源使用POST,GET,PUT,DELETE操作类似创建,读取,更新和删除(CRUD)操作. · 无状态.每个请求是一个独立的请求.从客户端到服务器的每个请求都必须包含所有必要的信息,

框架选型

前面的话 有一个流传较广的笑话,一个人在stackoverflow中提了一个问题,如何使用javascript实现一个数字与另外一个数字相加.最高票回答是你应该使用jQuery插件,jQuery插件可以做任何事情. 历史总是在重演,以前是jQuery,现在可能是react或vue.不同的框架有不同的应用场景,杀鸡不要用牛刀.本文将详细介绍框架选型 框架与库 库(lib)具有以下三个特点: 1.是针对特定问题的解答,具有专业性: 2.不控制应用的流程 3.被动的被调用 框架(frameword)具

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

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

设计模式解密(21)- 解释器模式

1.简介 定义:给定一个语言,定义它的文法表示,并定义一个解释器,这个解释器使用该标识来解释语言中的句子. 主要解决:对于一些固定文法构建一个解释句子的解释器. 本质:分离实现,解释执行.Interpreter模式其实就是一种简单的语法解释器构架. 英文:Interpreter 类型:行为型 2.类图及组成 (引)类图: 组成: AbstractExpression(抽象表达式):定义解释器的接口,约定解释器的解释操作. TerminalExpression(终结符表达式):用来实现语法规则中和