解释器模式与领域特定语言(DSL)详解
一、解释器模式的解析与应用
1.1 解析器的选择
当解释器中的内容可以自然地用 XML 或 YAML 表达时,应充分利用这些格式及其内置解析器。但如果语言不适合,就不要强行使用错误的格式来节省编码量。对于较为复杂的语言,若 XML 和 YAML 都不合适,可以考虑使用 Racc 这样的解析器生成器。Racc 以 UNIX 的 YACC 实用程序为模型,它接收语言的语法描述作为输入,输出用 Ruby 编写的解析器。不过,学习使用解析器生成器需要较长的时间和陡峭的学习曲线。
1.2 让 Ruby 进行解析
另一种思路是实现解释器模式,让用户可以用实际的 Ruby 代码编写程序。可以设计抽象语法树(AST)的 API,使代码编写自然,让用户可能意识不到自己在写 Ruby 代码。
1.3 解释器模式的使用与滥用
解释器模式在众多模式中较为独特,往往被低估和未充分利用。例如,早期数据库查询需要数据库专家费力编码,直到 SQL 等查询语言的出现;简单的 GUI 构建曾经需要软件工程师花费大量时间编写代码,而现在有了 HTML 等解释型语言,普通用户也能创建。
解释器模式被广泛忽视的原因可能是大多数软件工程师专注于业务问题,如数据库设计和 Web 应用开发,可能自大学课程后就没再深入思考过 AST 和解析器。但实际上,正确应用解释器模式能为系统增加独特的灵活性。
解释器存在一些技术缺点:
- 复杂性问题 :考虑解释器模式时,要思考语言的复杂程度,越简单越好。同时,要考虑编写程序的用户类型,有经验的
解释器模式与DSL详解
超级会员免费看
订阅专栏 解锁全文
995

被折叠的 条评论
为什么被折叠?



