[转]DSL-让你的 Ruby 代码更优秀

以下摘录

DSL和Gpl

DSL : domain-specific language。比如HTML是用于组织网页的‘语言’， CSS专门调整页面样式的‘语言’。

SQL是数据库操作的‘语句’。

GPL: general-purpose language。通用目的语言。即不是为了特定领域设计的语言。Ruby,Python,C都是。

简单的DSL

我们遇到不少的Ruby开源库都会有其对应DSL，其中就包括Rspec，Rabl，Capistrano等。今天就以自动化部署工具Capistrano来做个例子。Capistrano的简介如下A remote server automation and deployment tool written in Ruby.

它的作用通过定义相关的任务来声明一些需要在服务端完成的工作，并通过限定角色，让我们可以针对特定的主机完成特定的任务。配置文件大概是这样：

role :demo %w{example.com example.org example.net}

task :uptime do

  on roles(:demo) do |host|

    uptime = capture(:uptime)

    puts "#{host.hostname} reports: #{uptime}"

  end

end

从语义上分析，它完成了以下工作：

定义角色列表名demo, 列表中包含example.com等几个主机网址。
定义了任务 uptime, 然后通过方法on来定义任务流程和任务所针对的角色。
- 方法on的第一个参数是角色列表roles(:demo)
- 这个方法还接收一个代码块，并把主机对象host“暴露”（传）给代码块，以便运行对应的代码逻辑
任务代码块完成的功能：通过capture方法在远程主机上运行uptime命令，并把结果储存在变量内，然后把运行结果puts，即打印出来。

如果改用正常的Ruby代码来实现，代码可能如下：

demo = %w{example.com example.org example.net} # roles list

# uptime task

def uptime(host)

  uptime = capture(:uptime)

  puts "#{host.hostname} reports: #{uptime}"

end

demo.each do |hostname|

  host = Host.find_by(name: hostname)

  uptime(host)

end

可见对比起最初的DSL版本，这种实现方式的代码片段相对没那么紧凑，而且有些逻辑会含混不清，只能通过注释来阐明。

况且，Capistrano主要用于自动化一些远程作业，其中的角色列表，任务数量一般不会少。

当角色较多时我们不得不声明多个数组变量。
当任务较多的时候，则需要定义多个方法，然后在不同的角色中去调用，代码将越发难以维护。

这或许就是DSL的价值所在吧，把一些常规的操作定义成更清晰的特殊语法，接着我们便可以利用这些特殊语法来组织我们的代码，不仅提高了代码的可读性，还让后续编程工作变得更加简单。

⚠️。这是有争论的http://www.yinwang.org/blog-cn/2017/05/25/dsl

尽一切可能避免创造 DSL，因为它会带来严重的理解，交流和学习曲线问题，可能会严重的降低团队的工作效率。如果这个 DSL 是给用户使用，会严重影响用户体验，降低产品的可用性。

大部分时候写库代码，把需要的功能做成函数，其实就可以解决问题。

如果真的到了必须创造 DSL 的时候，非 DSL 不能解决问题，才可以动手设计 DSL。但 DSL 必须由程序语言专家来完成，否则它还是可能给产品和团队带来严重的后果。

大部分 DSL 要解决的问题，不过是“动态逻辑加载”。为了这个目的，你完全可以利用已有的语言（比如 JavaScript），或者取其中一部分构造，通过动态调用它的解释器（编译器）来达到这个目的，而不需要创造新的 DSL

构建一只青蛙

如果你想要了解一只青蛙，应该去构建它，而不是解剖它。

那么接下来我就尝试按照自己的理解去构建Capistrano的DSL，让我们自己的脚本也可以像Capistrano那样组织代码。

a. 主机类

从DSL中host变量的行为来看，需要把远程主机的信息封装的一个对象中。

设计方式：

不采用持久化机制：

在Host类内部维护一个主机列表，通过该类所定义的主机信息会被添加到列表内，并可以通过hostname进行查找。

class Host

  attr_accessor :hostname, :ip, :cpu, :memory

  @host_list = [] #所有被定义的主机都会被临时追加到这个列表中

  class << self

    def define(&block)

      host = Host.new

      block.call(host)

      @host_list << host

    end

    def find_by_name(hostname)

      @host_list.find {|host| host.hostname == hostname}

    end

  end

end

以代码块的方式来定义相关主机信息，然后通过Host#find_by_name来查找相关的主机。

b. 捕获方法

capture方法从功能上来看应该是往远程主机发送指令，并获取运行的结果。与远程主机进行通信一般都会采用SSH协议，比如我们想要往远程主机发送系统命令(假设是uptime)的话可以

ssh user@xxx.xxx.xxx.xxx uptime

而在Ruby中要运行命令行指令可以通过特殊语法来包裹对应的系统命令。那么capture方法可以粗略实现成

def capture(command)

  `ssh #{@user}@#{@current_host} #{command}`

end

不过这里为了简化流程，我就不向远端主机发送命令了。而只是打印相关的信息，并始终返回success状态

def capture(command)

  # 不向远端主机发送系统命令，而是打印相关的信息，并返回:success

  puts "running command '#{command}' on #{@current_host.ip} by #{@user}"

  # `ssh #{@user}@#{@current_host.ip} #{command}`

  :success

end

该方法可以接收字符串或者符号类型。假设我们已经设置好变量@user的值为lan，而@current_host的值是192.168.1.218，那么运行结果如下

capture(:uptime) # => running command 'uptime' on 192.168.1.218 by lan

capture('uptime') # => running command 'uptime' on 192.168.1.218 by lan

c. 角色注册

从代码上来看，角色相关的DSL应该包含以下功能

通过role配合角色名，主机列表来注册相关的角色。
通过role配合角色名来获取角色对应的主机列表。

这两个功能其实可以简化成哈希表的取值，赋值操作。

不过我不想另外维护一个哈希表，我打算直接在当前环境中以可共享变量的方式来存储角色信息。

要知道我们平日所称的环境其实就是哈希表，而我们可以通过实例变量来达到共享的目的

def role(name, list)

  instance_variable_set("@role_#{name}", list)

end

def roles(name)

  instance_variable_get("@role_#{name}")

end

这样就可以实现角色注册，并在需要时取出来：

role :name, %w{ hello.com hello.net }

p roles(:name) # => ["hello.com", "hello.net"]

此外，这个简单的实现有个比较明显的问题，就是有可能会污染当前环境中已有的实例变量。不过一般而言这种几率并不是很大，注意命名就好。

d. 定义任务

在原始代码中我们通过关键字task，配合任务名还有代码块来划分任务区间。

在任务区间中通过关键字on来定义需要在特定的主机列表上执行的任务。

从这个阵仗上来在task所划分的任务区间中，可以利用多个on语句来指定需要运行在不同角色上的任务。

我们可以考虑把这些任务都塞入一个队列中，等到task的任务区间结束之后再依次调用。

按照这种思路task方法的功能反而简单了，只要能够接收代码块并打印一些基础的日志信息即可，当然还需要维护一个任务队列：

def task(name)

  puts "task #{name} end"

  @current_task = []  #@current_task可以被代码块（闭包）得到。

  yield if block_given?  #确认调用task方法后传入代码块了没有，有，执行这个代码块，即几个on方法。

  @current_task.each(&:call)  #在task方法中的on方法都执行完后，调用队列中的Proc对象。

  puts "task #{name} end"

end

定义on方法，它应该能定义需要在特定角色上运行的任务，并且把对应的任务追加到队列中，延迟执行。

延迟执行即使用

 @current_task << Proc.new do...end

把所有的任务放入队列中（@current_task），然后执行@current_task中的每一个Proc对象。

def on(list, &block)

   raise "You must provide the block of the task." unless block_given?

   @current_task << Proc.new do

     host_list = list.map {|name| Host.find_by_name(name)}

     host_list.each do |host|

       @current_host = host

       block.call(host)

     end

   end

end

e. 测试DSL

相关的DSL已经定义好了，下面来测试一下，从设计上来看需要我们预先设置主机信息，注册角色列表以及具有远程主机权限的用户

# 设定有远程主机权限的用户

@user = 'lan'

# 预设主机信息，一共三台主机

Host.define do |host|

  host.hostname = 'example.com'

  host.ip = '192.168.1.218'

  host.cpu = '2 core'

  host.memory = '8 GB'

end

Host.define do |host|

  host.hostname = 'example.org'

  host.ip = '192.168.1.110'

  host.cpu = '1 core'

  host.memory = '4 GB'

end

Host.define do |host|

  host.hostname = 'example.net'

  host.ip = '192.168.1.200'

  host.cpu = '1 core'

  host.memory = '8 GB'

end

## 注册角色列表

role :app, %w{example.com example.net}

role :db, %w{example.org}

接下来我们通过task和on配合上面所设置的基础信息来定义相关的任务：

这就是DSL的使用：本质上还是方法定义罢了（充分利用了Ruby的代码块）

task :demo do

  on roles(:app) do |host|

    uptime = capture(:uptime)

    puts "#{host.hostname} reports: #{uptime}"

    puts "------------------------------"

  end

  on roles(:db) do |host|

    uname = capture(:uname)

    puts "#{host.hostname} reports: #{uname}"

    puts "------------------------------"

  end

end

⚠️： on方法的第一参数是roles方法，第二个参数是代码块。

运行结果如下

task demo begin

running command 'uptime' on 192.168.1.218 by lan

example.com reports: success

------------------------------

running command 'uptime' on 192.168.1.200 by lan

example.net reports: success

------------------------------

running command 'uname' on 192.168.1.110 by lan

example.org reports: success

------------------------------

task demo end

这个就是我们所设计的DSL，与Capistrano所提供的基本一致，最大的区别在于我们不会往远程服务器发送系统命令，而是以日志的方式把相关的信息打印出来。从功能上看确实有点粗糙，不过语法上已经达到预期了。

尾声

这篇文章主要简要地介绍了一下DSL，如果细心观察会发现DSL在我们的编码生涯中几乎无处不在。Ruby的许多开源项目会利用语言自身的特征来设计相关的DSL，我用Capistrano举了个例子，对比起常规的编码方式，设计DSL能够让我们的代码更加清晰。最后我尝试按自己的理解去模拟Capistrano的部分DSL，其实只要懂得一点元编程的概念，这个过程还是比较容易的。

现在主流观点是能不用，就不用：

⚠️。这是有争论的http://www.yinwang.org/blog-cn/2017/05/25/dsl

尽一切可能避免创造 DSL，因为它会带来严重的理解，交流和学习曲线问题，可能会严重的降低团队的工作效率。
如果这个 DSL 是给用户使用，会严重影响用户体验，降低产品的可用性。

大部分时候写库代码，把需要的功能做成函数，其实就可以解决问题。

如果真的到了必须创造 DSL 的时候，非 DSL 不能解决问题，才可以动手设计 DSL。但 DSL 必须由程序语言专家来完成，否则它还是可能给产品和团队带来严重的后果。

大部分 DSL 要解决的问题，不过是“动态逻辑加载”。为了这个目的，你完全可以利用已有的语言（比如 JavaScript），或者取其中一部分构造，通过动态调用它的解释器（编译器）来达到这个目的，而不需要创造新的 DSL