人們都很喜歡討論閉包這個(gè)概念。其實(shí)這個(gè)概念對(duì)于寫代碼來講一點(diǎn)用都沒有，寫代碼只需要掌握好lambda表達(dá)式和class+interface的語義就行了。基本上只有在寫編譯器和虛擬機(jī)的時(shí)候才需要管什么是閉包。不過因?yàn)橄盗形恼轮黝}的緣故，在這里我就跟大家講一下閉包是什么東西。在理解閉包之前，我們得先理解一些常見的argument passing和symbol resolving的規(guī)則。

首先第一個(gè)就是call by value了。這個(gè)規(guī)則我們大家都很熟悉，因?yàn)榱餍械恼Z言都是這么做的。大家還記得剛開始學(xué)編程的時(shí)候，書上總是有一道題目，說的是：

void Swap(int a, int b)
{
    int t = a;
    a = b;
    b = t;
}

int main()
{
    int a=0;
    int b=1;
    Swap(a, b);
    printf("%d, %d", a, b);
}

然后問程序會(huì)輸出什么。當(dāng)然我們現(xiàn)在都知道，a和b仍然是0和1，沒有受到變化。這就是call by value。如果我們修改一下規(guī)則，讓參數(shù)總是通過引用傳遞進(jìn)來，因此Swap會(huì)導(dǎo)致main函數(shù)最后會(huì)輸出1和0的話，那這個(gè)就是call by reference了。

除此之外，一個(gè)不太常見的例子就是call by need了。call by need這個(gè)東西在某些著名的實(shí)用的函數(shù)式語言（譬如Haskell）是一個(gè)重要的規(guī)則，說的就是如果一個(gè)參數(shù)沒被用上，那傳進(jìn)去的時(shí)候就不會(huì)執(zhí)行。聽起來好像有點(diǎn)玄，我仍然用C語言來舉個(gè)例子。

int Add(int a, int b)
{
    return a + b;
}

int Choose(bool first, int a, int b)
{
    return first ? a : b;
}

int main()
{
    int r = Choose(false, Add(1, 2), Add(3, 4));
    printf("%d", r);
}

這個(gè)程序Add會(huì)被調(diào)用多少次呢？大家都知道是兩次。但是在Haskell里面這么寫的話，就只會(huì)被調(diào)用一次。為什么呢？因?yàn)镃hoose的第一個(gè)參數(shù)是false，所以函數(shù)的返回值只依賴與b，而不依賴與a。所以在main函數(shù)里面它感覺到了這一點(diǎn)，于是只算Add(3, 4)，不算Add(1, 2)。不過大家別以為這是因?yàn)榫幾g器優(yōu)化的時(shí)候內(nèi)聯(lián)了這個(gè)函數(shù)才這么干的，Haskell的這個(gè)機(jī)制是在運(yùn)行時(shí)起作用的。所以如果我們寫了個(gè)快速排序的算法，然后把一個(gè)數(shù)組排序后只輸出第一個(gè)數(shù)字，那么整個(gè)程序是O(n)時(shí)間復(fù)雜度的。因?yàn)榭焖倥判虻腶verage case在把第一個(gè)元素確定下來的時(shí)候，只花了O(n)的時(shí)間。再加上整個(gè)程序只輸出第一個(gè)數(shù)字，所以后面的他就不算了，于是整個(gè)程序也是O(n)。

于是大家知道call by name、call by reference和call by need了。現(xiàn)在來給大家講一個(gè)call by name的神奇的規(guī)則。這個(gè)規(guī)則神奇到，我覺得根本沒辦法駕馭它來寫出一個(gè)正確的程序。我來舉個(gè)例子：

int Set(int a, int b, int c, int d)
{
    a += b;
    a += c;
    a += d;
}

int main()
{
    int i = 0;
    int x[3] = {1, 2, 3};
    Set(x[i++], 10, 100, 1000);
    printf("%d, %d, %d, %d", x[0], x[1], x[2], i);
}

學(xué)過C語言的都知道這個(gè)程序其實(shí)什么都沒做。如果把C語言的call by value改成了call by reference的話，那么x和i的值分別是{1111, 2, 3}和1。但是我們知道，人類的想象力是很豐富的，于是發(fā)明了一種叫做call by name的規(guī)則。call by name也是call by reference的，但是區(qū)別在于你每一次使用一個(gè)參數(shù)的時(shí)候，程序都會(huì)把計(jì)算這個(gè)參數(shù)的表達(dá)式執(zhí)行一遍。因此，如果把C語言的call by value換成call by name，那么上面的程序做的事情實(shí)際上就是：

x[i++] += 10;
x[i++] += 100;
x[i++] += 1000;

程序執(zhí)行完之后x和i的值就是{11, 102, 1003}和3了。

很神奇對(duì)吧，稍微不注意就會(huì)中招，是個(gè)大坑，基本沒法用對(duì)吧。那你們還整天用C語言的宏來代替函數(shù)干什么呢。我依稀記得Ada（有網(wǎng)友指出這是Algol 60）還是什么語言就是用這個(gè)規(guī)則的，印象比較模糊。

講完了argument passing的事情，在理解lambda表達(dá)式之前，我們還需要知道兩個(gè)流行的symbol resolving的規(guī)則。所謂的symbol resolving講的就是解決程序在看到一個(gè)名字的時(shí)候，如何知道這個(gè)名字到底指向的是誰的問題。于是我又可以舉一個(gè)簡(jiǎn)單粗暴的例子了：

Action<int> SetX()
{
    int x = 0;
    return (int n)=>
    {
        x = n;
    };
}

void Main()
{
    int x = 10;
    var setX = SetX();
    setX(20);
    Console.WriteLine(x);
}

弱智都知道這個(gè)程序其實(shí)什么都沒做，就輸出10。這是因?yàn)镃#用的symbol resolving地方法是lexical scoping。對(duì)于SetX里面那個(gè)lambda表達(dá)式來講，那個(gè)x是SetX的x而不是Main的x，因?yàn)閘exical scoping的含義就是，在定義的地方向上查找名字。那為什么不能在運(yùn)行的時(shí)候向上查找名字從而讓SetX里面的lambda表達(dá)式實(shí)際上訪問的是Main函數(shù)里面的x呢？其實(shí)是有人這么干的。這種做法叫dynamic scoping。我們知道，著名的javascript語言的eval函數(shù)，字符串參數(shù)里面的所有名字就是在運(yùn)行的時(shí)候查找的。

=======================我是背景知識(shí)的分割線=======================

想必大家都覺得，如果一個(gè)語言的lambda表達(dá)式在定義和執(zhí)行的時(shí)候采用的是lexical scoping和call by value那該有多好呀。流行的語言都是這么做的。就算規(guī)定到這么細(xì)，那還是有一個(gè)分歧。到底一個(gè)lambda表達(dá)式抓下來的外面的符號(hào)是只讀的還是可讀寫的呢？python告訴我們，這是只讀的。C#和javascript告訴我們，這是可讀寫的。C++告訴我們，你們自己來決定每一個(gè)符號(hào)的規(guī)則。作為一個(gè)對(duì)語言了解得很深刻，知道自己每一行代碼到底在做什么，而且還很有自制力的程序員來說，我還是比較喜歡C#那種做法。因?yàn)槠鋵?shí)C++就算你把一個(gè)值抓了下來，大部分情況下還是不能優(yōu)化的，那何苦每個(gè)變量都要我自己說明我到底是想只讀呢，還是要讀寫都可以呢？函數(shù)體我怎么用這個(gè)變量不是已經(jīng)很清楚的表達(dá)出來了嘛。

那說到底閉包是什么呢？閉包其實(shí)就是那個(gè)被lambda表達(dá)式抓下來的“上下文”加上函數(shù)本身了。像上面的SetX函數(shù)里面的lambda表達(dá)式的閉包，就是x變量。一個(gè)語言有了帶閉包的lambda表達(dá)式，意味著什么呢？我下面給大家展示一小段代碼。現(xiàn)在要從動(dòng)態(tài)類型的的lambda表達(dá)式開始講，就湊合著用那個(gè)無聊的javascript吧：

function pair(a, b) {
    return function(c) {
        return c(a, b);
    };
}

function first(a, b) {
    return a;
}

function second(a, b) {
    return b;
}

var p = pair(1, pair(2, 3));
var a = p(first);
var b = p(second)(first);
var c = p(second)(second);
print(a, b, c);

這個(gè)程序的a、b和c到底是什么值呢？當(dāng)然就算看不懂這個(gè)程序的人也可以很快猜出來他們是1、2和3了，因?yàn)樽兞棵麑?shí)在是定義的太清楚了。那么程序的運(yùn)行過程到底是怎么樣的呢？大家可以看到這個(gè)程序的任何一個(gè)值在創(chuàng)建之后都沒有被第二次賦值過，于是這種程序就是沒有副作用的，那就代表其實(shí)在這里call by value和call by need是沒有區(qū)別的。call by need意味著函數(shù)的參數(shù)的求值順序也是無所謂的。在這種情況下，程序就變得跟數(shù)學(xué)公式一樣，可以推導(dǎo)了。那我們現(xiàn)在就來推導(dǎo)一下：

var p = pair(1, pair(2, 3));
var a = p(first);

// ↓↓↓↓↓

var p = function(c) {
    return c(1, pair(2, 3));
};
var a = p(first);

// ↓↓↓↓↓

var a = first(1, pair(2, 3));

// ↓↓↓↓↓

var a = 1;

這也算是個(gè)老掉牙的例子了啊。閉包在這里體現(xiàn)了他強(qiáng)大的作用，把參數(shù)保留了起來，我們可以在這之后進(jìn)行訪問。仿佛我們寫的就是下面這樣的代碼：

var p = {
    first : 1,
    second : {
        first : 1,
        second : 2,
    }
};

var a = p.first;
var b = p.second.first;
var c = p.second.second;

于是我們得到了一個(gè)結(jié)論，（帶閉包的）lambda表達(dá)式可以代替一個(gè)成員為只讀的struct了。那么，成員可以讀寫的struct要怎么做呢？做法當(dāng)然跟上面的不一樣。究其原因，就是因?yàn)閖avascript使用了call by value的規(guī)則，使得pair里面的return c(a, b);沒辦法將a和b的引用傳遞給c，這樣就沒有人可以修改a和b的值了。雖然a和b在那些c里面是改不了的，但是pair函數(shù)內(nèi)部是可以修改的。如果我們要堅(jiān)持只是用lambda表達(dá)式的話，就得要求c把修改后的所有“這個(gè)struct的成員變量”都拿出來。于是就有了下面的代碼：

// 在這里我們繼續(xù)使用上面的pair、first和second函數(shù)

function mutable_pair(a, b) {
    return function(c) {
        var x = c(a, b);
        // 這里我們把pair當(dāng)鏈表用，一個(gè)(1, 2, 3)的鏈表會(huì)被儲(chǔ)存為pair(1, pair(2, pair(3, null)))
        a = x(second)(first);
        b = x(second)(second)(first);
        return x(first);
    };
}

function get_first(a, b) {
    return pair(a, pair(a, pair(b, null)));
}

function get_second(a, b) {
    return pair(b, pair(a, pair(b, null)));
}

function set_first(value) {
    return function(a, b) {
        return pair(undefined, pair(value, pair(b, null)));
    };
}

function set_second(value) {
    return function(a, b) {
        return pair(undefined, pair(a, pair(value, null)));
    };
}

var p = mutable_pair(1, 2);
var a = p(get_first);
var b = p(get_second);
print(a, b);
p(set_first(3));
p(set_second(4));
var c = p(get_first);
var d = p(get_second);
print(c, d);

我們可以看到，因?yàn)間et_first和get_second做了一個(gè)只讀的事情，所以返回的鏈表的第二個(gè)值（代表新的a）和第三個(gè)值（代表新的b）都是舊的a和b。但是set_first和set_second就不一樣了。因此在執(zhí)行到第二個(gè)print的時(shí)候，我們可以看到p的兩個(gè)值已經(jīng)被更改成了3和4。

雖然這里已經(jīng)涉及到了“綁定過的變量重新賦值”的事情，不過我們還是可以嘗試推導(dǎo)一下，究竟p(set_first(3));的時(shí)候究竟干了什么事情：

var p = mutable_pair(1, 2);
p(set_first(3));

// ↓↓↓↓↓

p = return function(c) {
    var x = c(1, 2);
    a = x(second)(first);
    b = x(second)(second)(first);
    return x(first);
};
p(set_first(3));

// ↓↓↓↓↓

var x = set_first(3)(1, 2);
p.a = x(second)(first); // 這里的a和b是p的閉包內(nèi)包含的上下文的變量了，所以這么寫會(huì)清楚一點(diǎn)
p.b = x(second)(second)(first);
// return x(first);出來的值沒人要，所以省略掉。

// ↓↓↓↓↓

var x = (function(a, b) {
    return pair(undefined, pair(3, pair(b, null)));
})(1, 2);
p.a = x(second)(first);
p.b = x(second)(second)(first);

// ↓↓↓↓↓

x = pair(undefined, pair(3, pair(2, null)));
p.a = x(second)(first);
p.b = x(second)(second)(first);

// ↓↓↓↓↓

p.a = 3;
p.b = 2;

由于涉及到了上下文的修改，這個(gè)推導(dǎo)嚴(yán)格上來說已經(jīng)不能叫推導(dǎo)了，只能叫解說了。不過我們可以發(fā)現(xiàn)，僅僅使用可以捕捉可讀寫的上下文的lambda表達(dá)式，已經(jīng)可以實(shí)現(xiàn)可讀寫的struct的效果了。而且這個(gè)struct的讀寫是通過getter和setter來實(shí)現(xiàn)的，于是只要我們寫的復(fù)雜一點(diǎn)，我們就得到了一個(gè)interface。于是那個(gè)mutable_pair，就可以看成是一個(gè)構(gòu)造函數(shù)了。

大括號(hào)不能換行的代碼真他媽的難讀啊，遠(yuǎn)遠(yuǎn)望去就像一坨屎！go語言還把javascript自動(dòng)補(bǔ)全分號(hào)的算法給抄去了，真是沒品位。

所以，interface其實(shí)跟lambda表達(dá)是一樣，也可以看成是一個(gè)閉包。只是interface的入口比較多，lambda表達(dá)式的入口只有一個(gè)（類似于C++的operator()）。大家可能會(huì)問，class是什么呢？class當(dāng)然是interface內(nèi)部不可告人的實(shí)現(xiàn)細(xì)節(jié)的。我們知道，依賴實(shí)現(xiàn)細(xì)節(jié)來編程是不對(duì)的，所以我們要依賴接口編程。

當(dāng)然，即使是倉促設(shè)計(jì)出javascript的那個(gè)人，大概也是知道構(gòu)造函數(shù)也是一個(gè)函數(shù)的，而且類的成員跟函數(shù)的上下文鏈表的節(jié)點(diǎn)對(duì)象其實(shí)沒什么區(qū)別。于是我們會(huì)看到，javascript里面是這么做面向?qū)ο蟮氖虑榈模?

function rectangle(a, b) {
    this.width = a;
    this.height = height;
}

rectangle.prototype.get_area = function() {
    return this.width * this.height;
};

var r = new rectangle(3, 4);
print(r.get_area());

然后我們就拿到了一個(gè)3×4的長方形的面積12了。不過javascript給我們帶來的一點(diǎn)點(diǎn)小困惑是，函數(shù)的this參數(shù)其實(shí)是dynamic scoping的，也就是說，這個(gè)this到底是什么，要看你在哪如何調(diào)用這個(gè)函數(shù)。于是其實(shí)

obj.method(args)

整個(gè)東西是一個(gè)語法，它代表method的this參數(shù)是obj，剩下的參數(shù)是args。可惜的是，這個(gè)語法并不是由“obj.member”和“func(args)”組成的。那么在上面的例子中，如果我們把代碼改為：

var x = r.get_area;
print(x());

結(jié)果是什么呢？反正不是12。如果你在C#里面做這個(gè)事情，效果就跟javascript不一樣了。如果我們有下面的代碼：

class Rectangle
{
    public int width;
    public int height;

    public int GetArea()
    {
        return width * height;
    }
};

那么下面兩段代碼的意思是一樣的：

var r = new Rectangle
{
    width = 3;
    height = 4;
};

// 第一段代碼
Console.WriteLine(r.GetArea());

// 第二段代碼
Func<int> x = r.GetArea;
Console.WriteLine(x());

究其原因，是因?yàn)閖avascript把obj.method(a, b)解釋成了GetMember(obj, “method”).Invoke(a, b, this = r);了。所以你做r.get_area的時(shí)候，你拿到的其實(shí)是定義在rectangle.prototype里面的那個(gè)東西。但是C#做的事情不一樣，C#的第二段代碼其實(shí)相當(dāng)于：

Func<int> x = ()=>
{
    return r.GetArea();
};
Console.WriteLine(x());

所以說C#這個(gè)做法比較符合直覺啊，為什么dynamic scoping（譬如javascript的this參數(shù)）和call by name（譬如C語言的宏）看起來都那么屌絲，總是讓人掉坑里，就是因?yàn)檫`反了直覺。不過javascript那么做還是情有可原的。估計(jì)第一次設(shè)計(jì)這個(gè)東西的時(shí)候，收到了靜態(tài)類型語言太多的影響，于是把obj.method(args)整個(gè)當(dāng)成了一個(gè)整體來看。因?yàn)樵贑++里面，this的確就是一個(gè)參數(shù)，只是她不能讓你obj.method，得寫&TObj::method，然后還有一個(gè)專門填this參數(shù)的語法——沒錯(cuò)，就是.*和->*操作符了。

假如說，javascript的this參數(shù)要做成lexical scoping，而不是dynamic scoping，那么能不能用lambda表達(dá)式來模擬interface呢？這當(dāng)然是可以，只是如果不用prototype的話，那我們就會(huì)喪失javascript愛好者們千方百計(jì)絞盡腦汁用盡奇技淫巧鎖模擬出來的“繼承”效果了：

function mutable_pair(a, b) {
    _this = {
        get_first = function() { return a; },
        get_second = function() { return b; },
        set_first = function(value) { a = value; },
        set_second = function(value) { b = value; }
    };
    return _this; 
}

var p = new mutable_pair(1, 2);
var a = p.get_first();
var b = p.get_second();
print(a, b);
var c = p.set_first(3);
var d = p.set_second(4);
print(c, d);

這個(gè)時(shí)候，即使你寫

var x = p.set_first;
var y = p.set_second;
x(3);
y(4);

代碼也會(huì)跟我們所期望的一樣正常工作了。而且創(chuàng)造出來的r，所有的成員變量都屏蔽掉了，只留下了幾個(gè)函數(shù)給你。與此同時(shí)，函數(shù)里面訪問_this也會(huì)得到創(chuàng)建出來的那個(gè)interface了。

大家到這里大概已經(jīng)明白閉包、lambda表達(dá)式和interface之間的關(guān)系了吧。我看了一下之前寫過的六篇文章，加上今天這篇，內(nèi)容已經(jīng)覆蓋了有：

1. 閱讀C語言的復(fù)雜的聲明語法
2. 什么是語法噪音
3. 什么是語法的一致性
4. C++的const的意思
5. C#的struct和property的問題
6. C++的多重繼承
7. 封裝到底意味著什么
8. 為什么exception要比error code寫起來干凈、容易維護(hù)而且不需要太多的溝通
9. 為什么C#的有些interface應(yīng)該表達(dá)為concept
10. 模板和模板元編程
11. 協(xié)變和逆變
12. type rich programming
13. OO的消息發(fā)送的含義
14. 虛函數(shù)表是如何實(shí)現(xiàn)的
15. 什么是OO里面的類型擴(kuò)展開放/封閉與邏輯擴(kuò)展開放/封閉
16. visitor模式如何逆轉(zhuǎn)類型和邏輯的擴(kuò)展和封閉
17. CPS（continuation passing style）變換與異步調(diào)用的異常處理的關(guān)系
18. CPS如何讓exception變成error code
19. argument passing和symbol resolving
20. 如何用lambda實(shí)現(xiàn)mutable struct和immutable struct
21. 如何用lambda實(shí)現(xiàn)interface

想了想，大概通俗易懂的可以自學(xué)成才的那些東西大概都講完了。當(dāng)然，系列是不會(huì)在這里就結(jié)束的，只是后面的東西，大概就需要大家多一點(diǎn)思考了。

寫程序講究行云流水。只有自己勤于思考，勤于做實(shí)驗(yàn)，勤于造輪子，才能讓編程的學(xué)習(xí)事半功倍。