Martin Fowler 揭示了他即将出版的关于 DSL 的新书的一些细节,在他的工作进展网站上发布了该书引言部分的第一稿。这本书很可能有一个“复式的”结构,包含一个叙述部分和一个以模式的形式展现若干 DSL 主题的参考部分。
引言草稿提供了 DSL 的一些背景元素。除了他以前的文章,Fowler 又在 Jaoo 2006 大会上以及最近于巴塞罗那举行的一次 TSS 活动中进一步发展了他的思想,在这些基础上,他举出了一个领域特定语言的案例并提出了一些对 DSL 的实现和使用的新见解。
在定义 DSL 是什么的问题上,Flowler 认为目前经常使用的一些特征,例如“关注于领域”、“有限的表现”和“语言本质”是非常模糊的。因此,唯一能够确定 DSL 边界的方法是考虑“一门语言的一种特定用法”和“该语言的设计者或使用者的意图”:
如果 XSLT 的设计者将其设计为 XML 的转换工具,那么我认为 XSLT 是一个 DSL。如果一个用户使用 DSL 的目的是该 DSL 所要达到的目的,那么它一个 DSL,但是如果有人以通用的方式来使用一个 DSL,那么它(在这种用法下)就不再是一个 DSL 了。
以 Fowler 的观点,DSL 首先是一种帮助用户从一个系统中抽象出某些部分的工具。所以“当你意识到你需要一个组件,或者当你已经有了一个组件而你希望简化操作它的方式的时候”,DSL 是有用的。使用 DSL 确实提供了某些益处。DSL 不仅提高了代码的易读性,让开发者可以和领域专家更好的交流,而且是改变执行上下文的一种手段,例如:把逻辑从编译时切换到运行时,或者当命令式编程不是很合适的时候转用声明式计算模型。
在 Fowler 所用的例子中,他在一个框架已经确定好的 API 之上实现 DSL。他强调也可以从 DSL 的设计开始动手。在这种情况下,应该首先定义“一套控制器行为的样本”,并以 DSL 的形式写出来。为了继续实现工作必须既构建框架和 API,同时也构建 DSL 的具体语法。有三种可能的途径:
有些人喜欢同时处理所有这些元素的一小部分:构建一部分组件功能,编写驱动这些功能的 DSL,然后用测试把它们串起来。其他人也许愿意先构建并测试框架,然后在框架之上加上 DSL 层。还有一些人也许喜欢先准备好 DSL,然后再构建库,最后将 DSL 与库装配在一起。
Fowler 还对 DSL 可能的应用提出了预见。一个最显而易见的应用是一个运行的程序可以由解释 —— 程序的即时执行产生 —— 或者由代码生成器产生。为了避免后一种情况带来的汇编层,开发者可以使用诸如 Javascript 的动态语言。在解释阶段有两种处理方法:“一步解释,DSL 中的每条语句立刻被分析和解释”或者“两步解释,首先将输入的 DSL 全部分析并转变为用抽象语言表示的程序,然后执行抽象形式的程序”。 Fowler 强调内部 DSL 通常是解释执行的,然而“目前外部 DSL 的教程通常假设你使用代码生成技术”,尽管 Fowler 的观点是外部 DSL 也应该使用解释执行的方式。
DSL 还可以用来产生可视化的表示,即领域的一个只读投影。这样可以为“很难有可编辑的形式”的任务例如创建一个图表这样的任务提供更多的选择。当“创建一个组件框架的困难工作”完成之后,附加这样的可视化实际上是容易的。
最后但是也很重要的是,Fowler 列出了与 DSL 的使用相关的一些问题。除了通常所诟病的问题 —— 构建的代价,语言不调和的风险,困难的设计 —— 以外,Fowler 强调了迁移的问题。他相信 DSL 的迁移非常类似于 API 的迁移。不同之处是缺乏工具,例如,重构的工具,特别是外部 DSL 尤其缺乏。对于迁移问题,有一些技术也许有用,例如,Migration Execution,Fowler 定义该技术为“令得到产生源代码所需的抽象层变得相对容易,可以具体化你希望作出的任何变化”。
Fowler 提出的另一个议题是需要一贯地当心不要让事情变得太复杂,不要让事情演化为一般性的问题。他提倡为了“特殊和困难的情形”引入另外的语言,将该语言置于基础 DSL 的上层。Fowler 相信与 DSL 使用相关的问题通常是言过其实的,源于“通常人们对于如何构建 DSL 不够熟悉,对于如何将 DSL 融入更广阔的软件开发的全景没有足够的认识”。
要得到这些议题以及相关议题的更多信息,请参考 Fowler’s Work in Progress on the book 。
查看英文原文: Martin Fowler unveils details of his upcoming DSL book - - - - - -
译者简介: 曹云飞,西安交通大学计算机软件硕士。现就职于 Ethos ,热衷于新技术的钻研,软件架构与敏捷开发,目前从事 Home Control 方面的工作。参与 InfoQ 中文站内容建设,请邮件至 china-editorial[at]infoq.com 。
评论