Skip to content

Files

Latest commit

db423ff · Aug 6, 2019

History

History
34 lines (24 loc) · 2.31 KB

interperter.md

File metadata and controls

34 lines (24 loc) · 2.31 KB

设计模式 -- 解释器模式

定义

给定一个语言,定义它的文法的一种表示,并定义一个解释器,该解释器使用该表示来解释语言中的句子。(其中语言就是我们需要解释的对象,文法就是这个语言的规律,解释器就是翻译机,通过文法来翻译语言。)

使用场景

  • 如果某个简单的语言需要解释执行而且可以将该语言中的语句表示为一个抽象的语法树时。
  • 在某些特定的领域出现不断重复的问题时,可以将该领域的问题转化为一种语法规则下的语句,然后构建解释器来解释该语句。

UML 类图

由上图,解释器模式 主要包含这几种角色:

  • AbstractExpression:抽象表达式,声明一个抽象的解释操作父类,并定义一个抽象的 interpret() 解释方法,其具体的实现在各个具体的子类解释器中完成。
  • TerminalExpression:终结符表达式,实现了抽象表达式角色所要求的接口,主要是一个interpret()方法;文法中的每一个终结符都有一个具体终结表达式与之相对应。
  • NonterminalExpression:非终结符表达式,实现与非终结符有关的解释操作
  • Context:上下文环境类,包含解释器之外的全部信息。
  • Client:客户类,解析表达式,构建抽象语法树,执行具体的解释操作等。

优缺点

  • 优点:
    • 最大的优点使其灵活的扩展性,当我们想对文法规则进行扩展延伸时,只需要增加相应的非终结符解释器,并在构建抽象语法树时,使用到新增的解释器对象进行具体的解释即可,非常方便。
  • 缺点:
    • 每个语法都要产生一个非终结符表达式,语法规则比较复杂时,就可能产生大量的类文件,为维护带来了非常多的麻烦。
    • 解释器模式由于使用了大量的循环和递归,效率是个问题,特别是用于解析复杂、冗长的语法时,效率是难以忍受的。

Android 源码中的解释器模式的实现

PackageParser

PackageParser是对AndroidManifest.xml配置文件进行读取的 详细可查看 有关PackageManager启动分析