软件架构设计——解释器模式

首先  我们需要理解一点：什么是架构模式呢？

架构模式是一个通用的、可重用的解决方案，用于在给定上下文中的软件体系结构中经常出现的问题。架构模式与软件设计模式类似，但具有更广泛的范围。

那么 什么是解释器模式呢？

这个模式用于设计一个解释用专用语言编写的程序的组件。它主要指定如何评估程序的行数，即以特定的语言编写的句子或表达式。其基本思想是为每种语言的符号都有一个分类。

 一、 模式定义

       所谓解释器模式就是定义语言的文法，并且建立一个解释器来解释该语言中的句子。

什么？不明白？

说的简单点，就是：给定一个语言，然后定义它的文法，并定义一个解释器，该解释器用该文法来解释语言中的句子。

在这里 ，如果你学过软件构造相关只是的话，相信已经理解了个七七八八。

二、使用场景

如果一种特定类型的问题发生的频率足够高，那么可能就值得将该问题的各个实例表述为一个简单语言中的句子.这样就可以构建一个解释器，该解释器通过解释这些句子来解决该问题.

举个例子：

数据库查询语言中的SQL语句。你只需要输入相应select语句，解释器便会分析SQL语句的文法，识别你想要找到的数据元素并把它提取出来。

 

    解释器模式主要包含如下几个角色：

          AbstractExpression: 抽象表达式。声明一个抽象的解释操作，该接口为抽象语法树中所有的节点共享。

          TerminalExpression: 终结符表达式。实现与文法中的终结符相关的解释操作。实现抽象表达式中所要求的方法。文法中每一个终结符都有一个具体的终结表达式与之相对应。

          NonterminalExpression: 非终结符表达式。为文法中的非终结符相关的解释操作。

          Context: 环境类。包含解释器之外的一些全局信息。

          Client: 客户类

优点： 1、 可扩展性比较好，灵活。  2、 增加了新的解释表达式的方式  3、 易于实现简单文法。
缺点： 可利用场景比较少   2、 对于复杂的文法比较难维护。3、解释器模式会引起类膨胀 4、解释器模式采用递归调用方法
使用场景：1、可以将一个需要解释执行的语言中的句子表示为一个抽象语法树 2、一些重复出现的问题可以用一种简单的语言来进行表达 3、一个简单语法需要解释的场景 

三、模式总结：

   1、在解释器模式中由于语法是由很多类表示的，所以可扩展性强。

   2、虽然解释器的可扩展性强，但是如果语法规则的数目太大的时候，该模式可能就会变得异常复杂。所以解释器模式适用于文法较为简单的。

   3、解释器模式可以处理脚本语言和编程语言。常用于解决某一特定类型的问题频繁发生情况。

 

PS：本次博客是LZ吸收多位博主分享的经验总结而成  侵删。