代码块与函数对象

JavaScript、Ruby、Python 等动态语言对比 Java 有个很大的不同，就是让“过程”成了一种可以传递、修改甚至可以向它发送消息的对象。在 Ruby 中，这种对象称之为 Proc（本文称为“代码块”）；Python 和 JavaScript 中，任何一个函数和 lambda 表达式都是这样的对象。这种对象其实就是许多动态语言都有的“匿名函数” [3] 。

这种特性给了我们将过程保存为对象的可能性。在 C/C++ 里面也有函数指针的概念，但 C/C++ 并不支持随处定义过程，只能把全局定义好的函数用函数指针引用，所以相比之下 Ruby&Python 的这种特性能带来更多的便捷。这种便捷带给我们的，是可以让一部分 GoF 设计模式实现简化，因为 GoF 模式中有大量的行为模式，是和保存过程密切相关的，例如命令模式（Command）、策略模式（Strategy）。

这种“函数对象”和 GoF 命令模式本质上有相同点：

• 函数（Command 对象）的定义初始化了一个将被执行的过程；
• 对这个函数（Command 对象）调用一定的方法（圆括号调用或者发送 execute 消息）会执行预定义好的过程。

这么一来，我们就有可能用这种“函数对象”替代部分“命令对象”。举个简单的例子，点击一个按钮，触发删除文件的动作。假设 Java 中实现这点所使用的 GUI 框架依赖一个 ActionCommand 接口：

public interface ActionCommand {
    public void execute();
}

那么我们要做的就是将删除文件的操作封装为实现了 ActionCommand 接口的命令对象。

public class DeleteFileCommand implements ActionCommand {
    public void execute() {
        File file = new File("/tmp/somefile");
        if(file.isFile() && file.exists()) { file.delete(); }
    }
}

最终使用的时候，讲这个命令对象实例化并传递给 GUI 框架即可。

// omit...
button.setClickAction(new DeleteFileCommand());
// omit...

// 我们知道 GUI 框架内部会在按钮被点击的时候执行这个命令：
ActionCommand clickAction = this.clickAction;
clickAction.execute();

实现有些繁琐，但是我们在 Java 中似乎也较难找到更好的实现方式，毕竟我们要做到的是“保存一个过程，需要的时候才执行”。但是如果在 Python 中呢？我想大多数 Pythoner 不会选择去这么繁琐的方式，因为这样不 Pythonic。事实上，这样不仅不 Pythonic，也不 Ruby Style、JavaScript Style。在支持函数对象（或者代码块、匿名函数，随便怎么叫）的语言中，我们都可以选择更简单、更直观的方式。

import os
import ttk  # ``from tkinter import ttk`` for py3k

def deletefile():
    path = "/tmp/somefile"
    if os.path.exists(path) and os.path.isfile(path):
        os.remove(path)

root = ttk.Frame()
ttk.Button(root, command=deletefile).pack()
root.pack()
root.mainloop()

这也是我认为简单的命令模式将会融入语言的依据，因为从本质上来看，命令即过程。

当然，这种用函数对象定义命令的方式也有缺陷。第一个缺陷是对有接口强迫症的同学来说，不定义个接口去约束 Command 会很难受，这点不予评论，我坚持认为会游泳的就是鸭子 [4] ，干嘛非得有鸭子的 DNA。第二个缺陷是如果不能硬编码被删除文件的路径，需要通过参数传入怎么办？或者说的更通用一些，如果命令对象需要传入参数怎么办？在 Java 里面，我们可以：

public class DeleteFileCommand implements ActionCommand {
    private String path;
    public DeleteFileCommand(String path) { this.path = path; }
    public void execute() { /* omit */ }
}
button.setClickAction(new DeleteFileCommand("/tmp/somefile"));

似乎对于这点函数对象就无能为力了，所以我们这时候需要借助另一个有力的工具——词法闭包。

高阶函数与闭包

高阶函数似乎是来自函数式编程 [5] 领域的一个概念，简单来说就是调用一个函数，这个函数返回一个函数。这点在 JavaScript 里面实现的最优雅，也最常用：

var pow = function (base) {
  return function(num) {
      var result = num;
      for(var i=1; i<base; i++) {
        result = result*num;
      }
      return result;
    };
}

var pow2 = pow(2);
console.log(pow2(8)); // output: 64

这种特性其实就是“函数对象”的一种体现，它给了我们另一种便捷：通过函数生产函数，也就是通过一个函数来定制 过程 。这种定制本质上和 GoF 设计模式中的许多行为模式是一致的，上面一段计算次方的 JavaScript 可以等价于下面通过类来实现的 Java 代码：

public class Pow {
    private int base;
    public Pow(int base) { this.base = base; }
    public int getValueOf(int num) {
        int result = num;
        for (int i=1; i<this.base; i++) { result = result * num; }
        return result;
    }
}
Pow pow2 = new Pow(2); // use it
System.out.println(pow2.getValueOf(8));

这段代码和“函数对象”中的范例有微小的不同——JavaScript 版的 pow 函数成功地等价了 Java 版“带参数构造”的实现。仔细观察 pow 中返回的匿名函数对象，就会发现其中引用了一个属于外部作用域（也就是该匿名函数自身所在作用域）的变量 base 。这样乍看没问题，但是仔细推敲不合逻辑：在内部匿名函数被返回之后， pow 函数的一次调用应该已经结束了，其作用域中的变量应该被回收，为何还在匿名函数中可用呢？这就归结于[词法闭包][4]。在 Python、Ruby、Scala、JavaScript 等语言中，词法闭包一般就称呼为“闭包”，我使用全称是因为我曾被严重困扰过——这里的闭包（Closure） [6] 和数学中的闭包（也是 Closure） [7] 没有任何关系。

维基百科对于这里的闭包定义是这样的：

在计算机科学中，闭包（Closure）是词法闭包（Lexical Closure）的简称，是引用了自由变量的函数。这个被引用的自由变量将和这个函数一同存在，即使已经离开了创造它的环境也不例外。

也就是说，一个高阶函数内部的局部变量，被更深一层作用域的函数（也就是被返回的函数）内部的作用域引用之后，其生命期就会被绑定到内部的函数，只要该内部函数生命期未终结，即使高阶函数的生命期已经终结，该变量仍然活着。换言之，闭包让该过程附带上了额外的数据，这样就让过程在一定的情况下可等同于一个类的实例。关于闭包的这一特性，我听过一个最好的描述，可惜不知道出自谁口：

类实例是绑定了行为的数据，闭包是绑定了数据的行为

也就是说，对于只有一个行为的类实例（例如简单的 Command 对象），闭包是完全可以做到等价的。这么一来，就弥补了我们上面用“函数对象”代替类定义实现命令模式的不足，因为我们可以通过闭包的方式让行为附带外部数据。上述“删除文件”的例子完全可以在 Python 中实现如下：

import os
import ttk

def delete_file(path):
    def execute():
        if os.path.exists(path) and os.path.isfile(path):
            os.remove(path)
    return execute

root = ttk.Frame()
ttk.Button(root, text="Remove",
           command=delete_file("/tmp/myfile")).pack()
root.pack()
root.mainloop()

又或者是 Ruby 中，实现如下：

require 'tk'

def delete_file(path)
  return lambda do
    File.delete(path) if File.exists?(path) and File.file?(path)
  end
end

root = TkRoot.new
TkButton.new(root) do
  text "Remove File"
  command delete_file("e:/test.txt")
  pack
end
root.mainloop

至此，我们已经可以完美地用函数对象（代码块）和闭包，代替只有一个 execute 方法的命令对象。

结语

无论是函数对象还是词法闭包，我相信都已经是高表达力语言中的常用工具。尤其是上述“简单命令模式”的实现，我相信很多 Pythoner 在使用这种做法的时候根本不会想到这个是“命令模式”。随着语言抽象表达能力越来越高，这些模式终将融于平平常常的代码中。类似的例子还有很多，Python 中大家惯用的装饰器（Decorator） [8] 语法、还有简单的策略模式、观察者模式，都是此列。

所以对于设计模式，我觉得 GoF 固然经典，但新近发展中的变化却不容忽视。大家惯用的手法融于语言，而新的设计模式又随之出现。而比起传统模式，新的模式往往抽象程度更高，更贴近“设计”而不是“编码”。例如来自 Ruby 的“惯例优于配置”模式、《Ruby 设计模式》一书作者提出的“你不会用到它”模式都是很好的思想指引。