zoukankan      html  css  js  c++  java
  • Atitit. 解释器模式框架选型 and应用场景attilax总结 oao

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

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

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

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

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

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

    4. TerminalExpressionNonterminalExpression是两个实现。 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:1466519819@qq.com

    转载请注明来源: 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  可以使用hbapi

    5.3. 表达式解析

    5.4. 翻译词典

    6.  解释器框架选型

    6.0.1.1. 最佳实践

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

    Expression4J   百度28

    MESP  解释器   20

    参考

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

  • 相关阅读:
    python 中的[::-1]
    python 闭包
    elastic
    文件上传进度条修改
    python decorator的理解
    同方爬虫--面试题
    js typeof
    浅谈软件项目实施
    数独·唯一性技巧(Uniqueness)-1
    数独二
  • 原文地址:https://www.cnblogs.com/attilax/p/5963784.html
Copyright © 2011-2022 走看看