开发复杂的外部DSL.docVIP

开发复杂的外部DSL 领域特定语言的定义 领域特定语言(DSL)是一类计算机程序语言，开发DSL可以解决某一个特定领域的问题。领域自身有多方面的内涵。它可能特指某一产业，比如保险、教育、航空、医疗等；它也可能是指一种方法或者技术，比如JavaEE、.NET、数据库、服务、消息、架构以及领域驱动设计。 开发DSL语言的目的在于，我们要以一种更优雅、更简洁的方式面对领域中的一些列挑战。之所以能够这样，是因为这个语言刚好够用于解决领域中唯一存在的一系列挑战，一点儿不多、也一点儿不少。当然，其他人如果也想使用同一种语言解决自己的问题的话，必然需要对语言进行一些扩展，但是依然算不上困难。开发DSL，其目的之一在于让DSL更加自然，这有别于通用目的的编程语言以及其他不是特定于领域的工具。 在本文中要重点区分两个概念，内部DSL和外部DSL。这是两种不同风格的DSL。理解哪种风格的DSL适用于哪种特定的问题域是非常重要的。本文并不会深入探究DSL的普遍定义以及内部与外部的DSL有什么区别。Martin Fowler和其他一些人已经对这个领域进行了思考，并积累了大量的经验。我建议你阅读这些文献以获取更多的细节。不过我会在本文中给出一个基本的理论框架。 内部DSL 内部DSL是指与项目中使用的通用目的编程语言(Java、C#或Ruby)紧密相关的一类DSL。它是基于通用编程语言实现的。 Rails框架被称为基于Ruby的DSL，用于管理Ruby开发的Web应用程序。Rails之所以被称为DSL，原因之一在于Rails应用了一些Ruby语言的特性，使得基于Rails编程看上去与基于通用目的的Ruby语言编程并不相同。 如果把Rails看作是一种语言，它应该是基于Ruby、以Ruby为根基的，同时它自身也有独立的特性。 我不确定Dave Thomas(PragDave)是不是把Rails都看作一个很大的DSL，不过他提到过一些Rails的特性是由不同的DSL支持的。其中一个可以看作DSL的示例就是Active Record Declarations。通过使用一些特定于领域模型实体关联中的简单术语，Rails开发者自己可以关注于高层实体的关联概念，而让DSL管理背后所有的复杂基础设施和操作。 无论Rails的创建者或者它众多的使用者将完整的Rails看作DSL，还是将其一些特性(Active Record Declarations)看作DSL都不重要，我在此讨论的是内部DSL。这种风格的DSL之所以被贴为内部的标签，是因为它与基本的编程语言关系紧密，并且实现于其上，同时DSL中包含了一些其他的技术，使它自身看上去更像是一种特定的编程语言。 根据Martin Fowler和Eric Evans的观点，框架或者程序库的API是否满足内部DSL的关键特征之一就是它是否有一个流畅(fluent)的接口。这样，你就能够用短小的对象表达式去组织一个原本很长的表达式，使它读起来更加自然。 我从事设计和使用流畅的API的工作已经有一段时间了。比如，我早期关于流畅API的主要经验都集中于Smalltalk。在Smalltalk的世界里，有两种方法可以开发和使用流畅的API。第一种是你可以让一个对象消息表达式(方法调用)的结果(返回值)成为下一条消息的接收者：(你可以使结果成为新的消息接收者) 1+2+4在上面的这行代码中，数字(对象)1接收到消息+，参数为数字(对象)2，运算后的结果是数字3(隐式。的)；数字3又成为下一个消息+的接收者，参数为数字4。(为了保持清晰，在Smalltalk中数字字面量不是原生类型，而是第一类对象。)这当然对我们所有人来说都是非常自然的，甚至于都没有从编程的角度去考虑。这就是问题所在了。我可以用下面的代码完成同样的事情： result：=1 add：2. result：=result add：4. 但是这看起来既不自然，也不流畅。第一个流畅的表达式清楚地告诉你结果是7；而第二个却不然。对于Smalltalk来说，由于这项技术并不只局限于数字数学领域，Smalltalk语言骨子里的流畅性很容易应用到很多不同领域的领域特定方面中去。另外，我建议你看一看Smalltalk的级联(cascades)特性，它是第二个支持流畅接口的语言特性。这里我只示范了第一种方法，因为现在的面向对象语言都支持这种方法(但有时支持的方式与此不同)。 这里的重点在于，对于API的流畅性而言，它的目的是为了可以更优雅、更有效地解决给定的领域问题，即使是领域专家看了也会感到很自然。这便是所谓的DSL了。 当然了，对于这个问题本是仁者见仁、智者见智的。对于给定的API，我们是否把它看作是DSL，完全取决于我们的选择。不过一定要认识到Martin Flowler和其他人将我上