翻譯連載 | JavaScript輕量級函數式編程-第7章: 閉包vs對象 |《你不知道的JS》姊妹篇

• 原文地址：Functional-Light-JS
• 原文做者：Kyle Simpson－《You-Dont-Know-JS》做者

關於譯者：這是一個流淌着滬江血液的純粹工程：認真，是 HTML 最堅實的樑柱；分享，是 CSS 裏最閃耀的一瞥；總結，是 JavaScript 中最嚴謹的邏輯。通過捶打磨練，成就了本書的中文版。本書包含了函數式編程之精髓，但願能夠幫助你們在學習函數式編程的道路上走的更順暢。比心。

譯者團隊（排名不分前後）：阿希、blueken、brucecham、cfanlife、dail、kyoko-df、l3ve、lilins、LittlePineapple、MatildaJin、冬青、pobusama、Cherry、蘿蔔、vavd317、vivaxy、萌萌、zhouyao

第 7 章: 閉包 vs 對象

數年前，Anton van Straaten 創造了一個很是有名且被經常引用的 禪理 來舉例和證明一個閉包和對象之間重要的關係。

德高望重的大師 Qc Na 曾經和他的學生 Anton 一塊兒散步。Anton 但願引導大師到一個討論裏，說到：大師，我曾據說對象是一個很是好的東西，是這樣麼？Qc Na 同情地看着他的學生回答到, 「愚笨的弟子，對象只不過是可憐人的閉包」

被批評後，Anton 離開他的導師並回到了本身的住處，致力於學習閉包。他認真的閱讀整個「匿名函數：終極……」系列論文和它的姐妹篇，而且實踐了一個基於閉包系統的小的 Scheme 解析器。他學了不少，盼望展示給他導師他的進步。

當他下一次與 Qc Na 一同散步時，Anton 試着提醒他的導師，說到 「導師，我已經勤奮地學習了這件事，我如今明白了對象真的是可憐人的閉包。」 ，Qc Na 用棍子戳了戳 Anton 迴應到，「你何時才能學會，閉包纔是可憐人的對象」。在那一刻， Anton 明白了什麼。

Anton van Straaten 6/4/2003

http://people.csail.mit.edu/g...

原帖儘管簡短，卻有更多關於起源和動機的內容，我強烈推薦爲了理解本章去閱讀原帖來調整你的觀念。

我觀察到不少人讀完這個會對其中的聰明智慧傻笑，卻繼續不改變他們的想法。可是，這個禪理（來自 Bhuddist Zen 觀點）促使讀者進入其中對立真相的辯駁中。因此，返回而且再讀一遍。

究竟是哪一個？是閉包是可憐的對象，仍是對象是可憐的閉包？或都不是？或都是？或者這只是爲了說明閉包和對象在某些方面是相同的方式？

還有它們中哪一個與函數式編程相關？拉一把椅子過來而且仔細考慮一下子。若是你願意，這一章將是一個精彩的迂迴之路，一個遠足。

達成共識

先肯定一點，當咱們談及閉包和對象咱們都達成了共識。咱們顯然是在 JavaScript 如何處理這兩種機制的上下文中進行討論的，而且特指的是討論簡單函數閉包（見第 2 章的「保持做用域」）和簡單對象（鍵值對的集合）。

一個簡單的函數閉包：

function outer() {
    var one = 1;
    var two = 2;

    return function inner(){
        return one + two;
    };
}

var three = outer();

three();            // 3

一個簡單的對象：

var obj = {
    one: 1,
    two: 2
};

function three(outer) {
    return outer.one + outer.two;
}

three( obj );        // 3

但提到「閉包「時，不少人會想不少額外的事情，例如異步回調甚至是封裝和信息隱藏的模塊模式。一樣，」對象「會讓人想起類、this、原型和大量其它的工具和模式。

隨着深刻，咱們會須要當心地處理部分額外的相關內容，可是如今，儘可能只記住閉包和對象最簡單的釋義 —— 這會減小不少探索過程當中的困惑。

相像

閉包和對象之間的關係可能不是那麼明顯。讓咱們先來探究它們之間的類似點。

爲了給此次討論一個基調，讓我簡述兩件事：

1. 一個沒有閉包的編程語言能夠用對象來模擬閉包。
2. 一個沒有對象的編程語言能夠用閉包來模擬對象。

換句話說，咱們能夠認爲閉包和對象是同樣東西的兩種表達方式。

狀態

思考下面的代碼：

function outer() {
    var one = 1;
    var two = 2;

    return function inner(){
        return one + two;
    };
}

var obj = {
    one: 1,
    two: 2
};

inner() 和 obj 對象持有的做用域都包含了兩個元素狀態：值爲 1 的 one 和值爲 2 的 two。從語法和機制來講，這兩種聲明狀態是不一樣的。但概念上，他們的確至關類似。

事實上，表達一個對象爲閉包形式，或閉包爲對象形式是至關簡單的。接下來，嘗試一下：

var point = {
    x: 10,
    y: 12,
    z: 14
};

你是否是想起了一些類似的東西？

function outer() {
    var x = 10;
    var y = 12;
    var z = 14;

    return function inner(){
        return [x,y,z];
    }
};

var point = outer();

注意： 每次被調用時 inner() 方法建立並返回了一個新的數組（亦然是一個對象）。這是由於 JS 不提供返回多個數據卻不包裝在一個對象中的能力。這並非嚴格意義上的一個違反咱們對象相似閉包的說明的任務，由於這只是一個暴露／運輸具體值的實現，狀態追蹤自己仍然是基於對象的。使用 ES6+ 數組解構，咱們能夠聲明地忽視這個臨時中間對象經過另外一種方式：var [x,y,z] = point()。從開發者工程學角度，值應該被單獨存儲而且經過閉包而不是對象來追蹤。

若是你有一個嵌套對象會怎麼樣？

var person = {
    name: "Kyle Simpson",
    address: {
        street: "123 Easy St",
        city: "JS'ville",
        state: "ES"
    }
};

咱們能夠用嵌套閉包來表示相同的狀態：

function outer() {
    var name = "Kyle Simpson";
    return middle();

    // ********************

    function middle() {
        var street = "123 Easy St";
        var city = "JS'ville";
        var state = "ES";

        return function inner(){
            return [name,street,city,state];
        };
    }
}

var person = outer();

讓咱們嘗試另外一個方向，從閉包轉爲對象：

function point(x1,y1) {
    return function distFromPoint(x2,y2){
        return Math.sqrt(
            Math.pow( x2 - x1, 2 ) +
            Math.pow( y2 - y1, 2 )
        );
    };
}

var pointDistance = point( 1, 1 );

pointDistance( 4, 5 );        // 5

distFromPoint(..) 封裝了 x1 和 y1，可是咱們也能夠經過傳入一個具體的對象做爲替代值：

function pointDistance(point,x2,y2) {
    return Math.sqrt(
        Math.pow( x2 - point.x1, 2 ) +
        Math.pow( y2 - point.y1, 2 )
    );
};

pointDistance(
    { x1: 1, y1: 1 },
    4,    // x2
    5    // y2
);
// 5

明確地傳入point 對象替換了閉包的隱式狀態。

行爲，也是同樣！

對象和閉包不只是表達狀態集合的方式，並且他們也能夠包含函數或者方法。將數據和行爲捆綁爲有一個充滿想象力的名字：封裝。

思考：

function person(name,age) {
    return happyBirthday(){
        age++;
        console.log(
            "Happy " + age + "th Birthday, " + name + "!"
        );
    }
}

var birthdayBoy = person( "Kyle", 36 );

birthdayBoy();            // Happy 37th Birthday, Kyle!

內部函數 happyBirthday() 封閉了 name 和 age ，因此內部的函數也持有了這個狀態。

咱們也能夠經過 this 綁定一個對象來獲取一樣的能力：

var birthdayBoy = {
    name: "Kyle",
    age: 36,
    happyBirthday() {
        this.age++;
        console.log(
            "Happy " + this.age + "th Birthday, " + this.name + "!"
        );
    }
};

birthdayBoy.happyBirthday();
// Happy 37th Birthday, Kyle!

咱們仍然經過 happyBrithday() 函數來表達對狀態數據的封裝，可是用對象代替了閉包。同時咱們沒有顯式給函數傳遞一個對象（如同先前的例子）；JavaScript 的 this 綁定能夠創造一個隱式的綁定。

從另外一方面分析這種關係：閉包將單個函數與一系列狀態結合起來，而對象卻在保有相同狀態的基礎上，容許任意數量的函數來操做這些狀態。

事實上，咱們能夠在一個做爲接口的閉包上將一系列的方法暴露出來。思考一個包含了兩個方法的傳統對象：

var person = {
    firstName: "Kyle",
    lastName: "Simpson",
    first() {
        return this.firstName;
    },
    last() {
        return this.lastName;
    }
}

person.first() + " " + person.last();
// Kyle Simpson

只用閉包而不用對象，咱們能夠表達這個程序爲：

function createPerson(firstName,lastName) {
    return API;

    // ********************

    function API(methodName) {
        switch (methodName) {
            case "first":
                return first();
                break;
            case "last":
                return last();
                break;
        };
    }

    function first() {
        return firstName;
    }

    function last() {
        return lastName;
    }
}

var person = createPerson( "Kyle", "Simpson" );

person( "first" ) + " " + person( "last" );
// Kyle Simpson

儘管這些程序看起來感受有點反人類，但它們實際上只是相同程序的不一樣實現。

（不）可變

許多人最初都認爲閉包和對象行爲的差異源於可變性；閉包會阻止來自外部的變化而對象則否則。可是，結果是，這兩種形式都有典型的可變行爲。

正如第 6 章討論的，這是由於咱們關心的是值的可變性，值可變是值自己的特性，不在於在哪裏或者如何被賦值的。

function outer() {
    var x = 1;
    var y = [2,3];

    return function inner(){
        return [ x, y[0], y[1] ];
    };
}

var xyPublic = {
    x: 1,
    y: [2,3]
};

在 outer() 中字面變量 x 存儲的值是不可變的 —— 記住，定義的基本類型如 2 是不可變的。可是 y 的引用值，一個數組，絕對是可變的。這點對於 xyPublic 中的 x 和 y 屬性也是徹底相同的。

經過指出 y 自己是個數組咱們能夠強調對象和閉包在可變這點上沒有關係，所以咱們須要將這個例子繼續拆解：

function outer() {
    var x = 1;
    return middle();

    // ********************

    function middle() {
        var y0 = 2;
        var y1 = 3;

        return function inner(){
            return [ x, y0, y1 ];
        };
    }
}

var xyPublic = {
    x: 1,
    y: {
        0: 2,
        1: 3
    }
};

若是你認爲這個如同 「世界是一隻馱着一隻一直馱下去的烏龜（對象）羣」，在最底層，全部的狀態數據都是基本類型，而全部基本類型都是不可變值。

不管是用嵌套對象仍是嵌套閉包表明狀態，這些被持有的值都是不可變的。

同構

同構這個概念最近在 JavaScript 圈常常被提出，它一般被用來指代碼能夠同時被服務端和瀏覽器端使用／分享。我不久之前寫了一篇博文說明這種對同構這個詞的使用是錯誤的，隱藏了它實際上確切和重要的意思。

這裏我是博文部分的節選：

同構的意思是什麼？固然，咱們能夠用數學詞彙，社會學或者生物學討論它。同構最廣泛的概念是你有兩個相似可是不相同的結構。

在這些全部的慣用法中，同構和相等的區別在這裏：若是兩個值在各方面徹底一致那麼它們相等，可是若是它們表現不一致卻仍有一對一或者雙向映射的關係那麼它們是同構。

換而言之，兩件事物A和B若是你可以映射（轉化）A 到 B 而且可以經過反向映射回到A那麼它們就是同構。

回想第 2 章的簡單數學回顧，咱們討論了函數的數學定義是一個輸入和輸出之間的映射。咱們指出這在學術上稱爲態射。同構是雙映（雙向）態射的特殊案例，它須要映射不只僅必須能夠從任意一邊完成，並且在任一方式下反應徹底一致。

不去思考這些關於數字的問題，讓咱們將同構關聯到代碼。再一次引用個人博文：

若是 JS 有同構的話是怎麼樣的？它多是一集合的 JS 代碼轉化爲了另外一集合的 JS 代碼，而且（重要的是）若是你原意的話，你能夠把轉化後的代碼轉爲以前的。

正如咱們以前經過閉包如同對象和對象如同閉包爲例聲稱的同樣，它們的表達能夠任意替換。就這一點來講，它們互爲同構。

簡而言之，閉包和對象是狀態的同構表示（及其相關功能）。

下次你聽到誰說 「X 與 Y 是同構的」，他們的意思是，「X 和 Y 能夠從二者中的任意一方轉化到另外一方，而且不管怎樣都保持了相同的特性。」

內部結構

因此，咱們能夠從咱們寫的代碼角度想象對象是閉包的一種同構展現。但咱們也能夠觀察到閉包系統能夠被實現，而且極可能是用對象實現的！

這樣想一下：在以下的代碼中， 在 outer() 已經運行後，JS 如何爲了 inner() 的引用保持對變量 x 的追蹤？

function outer() {
    var x = 1;

    return function inner(){
        return x;
    };
}

咱們會想到做用域，outer() 做爲屬性的對象實施設置全部的變量定義。所以，從概念上講，在內存中的某個地方，是相似這樣的。

scopeOfOuter = {
    x: 1
};

接下來對於 inner() 函數，一旦建立，它得到了一個叫作 scopeOfInner 的（空）做用域對象，這個對象被其 [[Prototype]] 鏈接到 scopeOfOuter 對象，近似這個：

scopeOfInner = {};
Object.setPrototypeOf( scopeOfInner, scopeOfOuter );

接着，當內部的 inner() 創建詞法變量 x 的引用時，實際更像這樣：

return scopeOfInner.x;

scopeOfInner 並無一個 x 的屬性，當他的 [[Prototype]] 鏈接到擁有 x 屬性的 scopeOfOuter時。經過原型委託訪問 scopeOfOuter.x 返回值是 1。

這樣，咱們能夠近似認爲爲何 outer() 的做用域甚至在當它執行完都被保留（經過閉包），這是由於 scopeOfInner 對象鏈接到 scopeOfOuter 對象，所以，使這個對象和它的屬性完整的被保存下來。

如今，這都只是概念。我沒有從字面上說 JS 引擎使用對象和原型。但它徹底有道理，它能夠一樣地工做。

許多語言實際上經過對象實現了閉包。另外一些語言用閉包的概念實現了對象。但咱們讓讀者使用他們的想象力思考這是如何工做的。

同根異枝

因此閉包和對象是等價的，對嗎？不徹底是，我打賭它們比你在讀本章前想的更加類似，可是它們仍有重要的區別點。

這些區別點不該當被視做缺點或者不利於使用的論點；這是錯誤的觀點。對於給定的任務，它們應該被視爲使一個或另外一個更適合（和可讀）的特色和優點。

結構可變性

從概念上講，閉包的結構不是可變的。

換而言之，你永遠不能從閉包添加或移除狀態。閉包是一個表示對象在哪裏聲明的特性（被固定在編寫／編譯時間），而且不受任何條件的影響 —— 固然假設你使用嚴格模式而且／或者沒有使用做弊手段例如 eval(..)。

注意： JS 引擎能夠從技術上過濾一個對象來清除其做用域中再也不被使用的變量，可是這是一個對於開發者透明的高級的優化。不管引擎是否實際作了這類優化，我認爲對於開發者來講假設閉包是做用域優先而不是變量優先是最安全的。若是你不想保留它，就不要封閉它（在閉包裏）！

可是，對象默認是徹底可變的，你能夠自由的添加或者移除（delete）一個對象的屬性／索引，只要對象沒有被凍結（Object.freeze(..)）

這或許是代碼能夠根據程序中運行時條件追蹤更多（或更少）狀態的優點。

舉個例子，讓咱們思考追蹤遊戲中的按鍵事件。幾乎能夠確定，你會考慮使用一個數組來作這件事：

function trackEvent(evt,keypresses = []) {
    return keypresses.concat( evt );
}

var keypresses = trackEvent( newEvent1 );

keypresses = trackEvent( newEvent2, keypresses );

注意：你可否認出爲何我使用 concat(..) 而不是直接對 keypresses 數組使用 push(..) 操做？由於在函數式編程中，咱們一般但願對待數組如同不可變數據結構，能夠被建立和添加，但不能直接改變。咱們剔除了顯式從新賦值帶來的邪惡反作用（稍後再做說明）。

儘管咱們不在改變數組的結構，但當咱們但願時咱們也能夠。稍後詳細介紹。

數組不是記錄這個 evt 對象的增加「列表」的僅有的方式。。咱們可使用閉包：

function trackEvent(evt,keypresses = () => []) {
    return function newKeypresses() {
        return [ ...keypresses(), evt ];
    };
}

var keypresses = trackEvent( newEvent1 );

keypresses = trackEvent( newEvent2, keypresses );

你看出這裏發生了什麼嗎？

每次咱們添加一個新的事件到這個「列表」，咱們建立了一個包裝了現有 keypresses() 方法（閉包）的新閉包，這個新閉包捕獲了當前的 evt 。當咱們調用 keypresses() 函數，它將成功地調用全部的內部方法，並建立一個包含全部獨立封裝的 evt 對象的中間數組。再次說明，閉包是一個追蹤全部狀態的機制；這個你看到的數組只是一個對於須要一個方法來返回函數中多個值的具體實現。

因此哪個更適合咱們的任務？毫無心外，數組方法可能更合適一些。閉包的不可變結構意味着咱們的惟一選項是封裝更多的閉包在裏面。對象默認是可擴展的，因此咱們須要增加這個數組就足夠了。

順便一提，儘管咱們表現出結構不可變或可變是一個閉包和對象之間的明顯區別，然而咱們使用對象做爲一個不可變數據的方法實際上使之更類似而非不一樣。

數組每次添加就創造一個新數組（經過 concat(..)）就是把數組對待爲結構不可變，這個概念上對等於經過適當的設計使閉包結構上不可變。

私有

當對比分析閉包和對象時可能你思考的第一個區分點就是閉包經過詞法做用域提供「私有」狀態，而對象將一切作爲公共屬性暴露。這種私有有一個精緻的名字：信息隱藏。

考慮詞法閉包隱藏：

function outer() {
    var x = 1;

    return function inner(){
        return x;
    };
}

var xHidden = outer();

xHidden();            // 1

如今一樣的狀態公開：

var xPublic = {
    x: 1
};

xPublic.x;            // 1

這裏有一些在常規的軟件工程原理方面明顯的區別 —— 考慮下抽象，這種模塊模式有着公有和私有 API 等等。可是讓咱們試着把咱們的討論侷限於函數式編程的觀點，畢竟，這是一本關於函數式編程的書！

可見性

彷佛隱藏信息的能力是一種理想狀態的跟蹤特性，可是我認爲函數式編程者可能持反對觀點。

在一個對象中管理狀態做爲公開屬性的一個優勢是這使你狀態中的全部數據更容易枚舉（迭代）。思考下你想訪問每個按鍵事件（從以前的那個例子）而且存儲到一個數據庫，使用一個這樣的工具：

function recordKeypress(keypressEvt) {
    // 數據庫實用程序
    DB.store( "keypress-events", keypressEvt );
}

If you already have an array -- just an object with public numerically-named properties -- this is very straightforward using a built-in JS array utility forEach(..):

若是你已經有一個數組，正好是一個擁有公開的用數字命名屬性的對象 —— 很是直接地使用 JS 對象的內建工具 forEach(..)：

keypresses.forEach( recordKeypress );

可是，若是按鍵列表被隱藏在一個閉包裏，你不得不在閉包內暴露一個享有特權訪問數據的公開 API 工具。

舉例而說，我能夠給咱們的閉包 —— keypresses 例子自有的 forEach 方法，如同數組內建的：

function trackEvent(
    evt,
    keypresses = {
        list() { return []; },
        forEach() {}
    }
) {
    return {
        list() {
            return [ ...keypresses.list(), evt ];
        },
        forEach(fn) {
            keypresses.forEach( fn );
            fn( evt );
        }
    };
}

// ..

keypresses.list();        // [ evt, evt, .. ]

keypresses.forEach( recordKeypress );

對象狀態數據的可見性讓咱們能更直接地使用它，而閉包遮掩狀態讓咱們更艱難地處理它。

Change Control

變動控制

若是詞法變量被隱藏在一個閉包中，只有閉包內部的代碼才能自由的從新賦值，在外部修改 x 是不可能的。

正如咱們在第 6 章看到的，提高代碼可讀性的惟一真相就是減小表面掩蓋，讀者必須能夠預見到每個給定變量的行爲。

詞法（做用域）在從新賦值上的局部就近原則是爲何我不認爲 const 是一個有幫助的特性的一個重要緣由。做用域（例如閉包）一般應該儘量小，這意味着從新賦值只會影響少量代碼。在上面的 outer() 中，咱們能夠快速地檢查到沒有一行代碼重設了 x，至此（x 的）全部意圖和目的表現地像一個常量。

這類保證對於咱們對函數純淨的信任是一個強有力的貢獻，例如。

換而言之，xPublic.x 是一個公開屬性，程序的任何部分都能引用 xPublic ，默認有重設 xPublic.x 到別的值的能力。這會讓不少行代碼須要被考慮。

這是爲何在第 6 章， 咱們視 Object.freeze(..) 爲使全部的對象屬性只讀（writable: false）的一個快速而凌亂的方式，讓它們不能被不可預測的重設。

不幸的是，Object.freeze(..) 是極端且不可逆的。

使有了閉包，你就有了一些能夠更改代碼的權限，而剩餘的程序是受限的。當咱們凍結一個對象，代碼中沒有任何部分能夠被重設。此外，一旦一個對象被凍結，它不能被解凍，因此全部屬性在程序運行期間都保持只讀。

在我想容許從新賦值可是在表層限制的地方，閉包比起對象更方便和靈活。在我不想從新賦值的地方，一個凍結的對象比起重複 const 聲明在我全部的函數中更方便一些。

許多函數式編程者在從新賦值上採起了一個強硬的立場：它不該該被使用。他們傾向使用 const 來使用全部閉包變量只讀，而且他們使用 Ojbect.freeze(..) 或者徹底不可變數據結構來防止屬性被從新賦值。此外，他們儘可能在每一個可能的地方減小顯式地聲明的／追蹤的變量，更傾向於值傳遞 —— 函數鏈，做爲參數被傳遞的 return 值，等等 —— 替代中間值存儲。

這本書是關於 JavaScript 中的輕量級函數式編程，這是一個我與核心函數式編程羣體有分歧的狀況。

我認爲變量從新賦值當被合理的使用時是至關有用的，它的明確性具備至關有可讀性。從經驗來看，在插入 debugger 或斷點或跟蹤表表達式時，調試工做要容易得多。

狀態拷貝

正如咱們在第 6 章學習的，防止反作用侵蝕代碼可預測性的最好方法之一是確保咱們將全部狀態值視爲不可變的，不管他們是否真的可變（凍結）與否。

若是你沒有使用特別定製的庫來提供複雜的不可變數據結構，最簡單知足要求的方法：在每次變化前複製你的對象或者數組。

數組淺拷貝很容易：只要使用 slice() 方法：

var a = [ 1, 2, 3 ];

var b = a.slice();
b.push( 4 );

a;            // [1,2,3]
b;            // [1,2,3,4]

對象也能夠相對容易地實現淺拷貝：

var o = {
    x: 1,
    y: 2
};

// 在 ES2017 之後，使用對象的解構：
var p = { ...o };
p.y = 3;

// 在 ES2015 之後：
var p = Object.assign( {}, o );
p.y = 3;

若是對象或數組中的值是非基本類型（對象或數組），使用深拷貝你不得不手動遍歷每一層來拷貝每一個內嵌對象。不然，你將有這些內部對象的共享引用拷貝，這就像給你的程序邏輯形成了一次大破壞。

你是否意識到克隆是可行的只是由於全部的這些狀態值是可見的而且能夠如此簡單地被拷貝？一堆被包裝在閉包裏的狀態會怎麼樣，你如何拷貝這些狀態？

那是至關乏味的。基本上，你不得不作一些相似以前咱們自定義 forEach API 的方法：提供一個閉包內層擁有提取或拷貝隱藏值權限的函數，並在這過程當中建立新的等價閉包。

儘管這在理論上是可行的，對讀者來講也是一種鍛鍊！這個實現的操做量遠遠不及你可能進行的任何真實程序的調整。

在表示須要拷貝的狀態時，對象具備一個更明顯的優點。

性能

從實現的角度看，對象有一個比閉包有利的緣由，那就是 JavaScript 對象一般在內存和甚至計算角度是更加輕量的。

可是須要當心這個廣泛的斷言：有不少東西能夠用來處理對象，這會抹除你從無視閉包轉向對象狀態追蹤得到的任何性能增益。

讓咱們考慮一個情景的兩種實現。首先，閉包方式實現：

function StudentRecord(name,major,gpa) {
    return function printStudent(){
        return `${name}, Major: ${major}, GPA: ${gpa.toFixed(1)}`;
    };
}

var student = StudentRecord( "Kyle Simpson", "kyle@some.tld", "CS", 4 );

// 隨後

student();
// Kyle Simpson, Major: CS, GPA: 4.0

內部函數 printStudeng() 封裝了三個變量：name、major 和 gpa。它維護這個狀態不管咱們是否傳遞引用給這個函數，在這個例子咱們稱它爲 student()。

如今看對象（和 this）方式：

function StudentRecord(){
    return `${this.name}, Major: ${this.major}, GPA: ${this.gpa.toFixed(1)}`;
}

var student = StudentRecord.bind( {
    name: "Kyle Simpson",
    major: "CS",
    gpa: 4
} );

// 隨後

student();
// Kyle Simpson, Major: CS, GPA: 4.0

student() 函數，學術上叫作「邊界函數」 —— 有一個硬性邊界 this 來引用咱們傳入的對象字面量，所以以後任何調用 student() 將使用這個對象做爲this，因而它的封裝狀態能夠被訪問。

兩種實現有相同的輸出：一個保存狀態的函數，可是關於性能，會有什麼不一樣呢？

注意：精準可控地判斷 JS 代碼片斷性能是很是困難的事情。咱們在這裏不會深刻全部的細節，可是我強烈推薦你閱讀《你不知道的 JS：異步和性能》這本書，特別是第 6 章「性能測試和調優」，來了解細節。

若是你寫過一個庫來創造持有配對狀態的函數，要麼在第一個片斷中調用 studentRecord(..)，要麼在第二個片斷中調用 StudentRecord.bind(..)的方式，你可能更多的關心它們兩的性能怎樣。檢查代碼，咱們能夠看到前者每次都必須建立一個新函數表達式。後者使用 bind(..)，沒有明顯的含義。

思考 bind(..) 在內部作了什麼的一種方式是建立一個閉包來替代函數，像這樣：

function bind(orinFn,thisObj) {
    return function boundFn(...args) {
        return origFn.apply( thisObj, args );
    };
}

var student = bind( StudentRecord, { name: "Kyle.." } );

這樣，看起來咱們的場景的兩種實現都是創造一個閉包，因此性能看似也是一致的。

可是，內置的 bind(..) 工具並不必定要建立閉包來完成任務。它只是簡單地建立了一個函數，而後手動設置它的內部 this 給一個指定的對象。這可能比起咱們使用閉包自己是一個更高效的操做。

咱們這裏討論的在每次操做上的這種性能優化是不值一提的。可是若是你的庫的關鍵部分被使用了成千上萬次甚至更多，那麼節省的時間會很快增長。許多庫 —— Bluebird 就是這樣一個例子，它已經完成移除閉包去使用對象的優化。

在庫的使用案例以外，持有配對狀態的函數一般在應用的關鍵路徑發生的次數相對很是少。相比之下，典型的使用是函數加狀態 —— 在任意一個片斷調用 student()，是更加常見的。

若是你的代碼中也有這樣的場景，你應該更多地考慮（優化）先後的性能對比。

歷史上的邊界函數一般具備一個至關糟糕的性能，可是最近已經被 JS 引擎高度優化。若是你在幾年前檢測過這些變化，極可能跟你如今用最近的引擎重複測試的結果徹底不一致。

邊界函數如今看起來至少跟一樣的封裝函數表現的同樣好。因此這是另外一個支持對象比閉包好的點。

我只想重申：性能觀察結果不是絕對的，在一個給定場景下決定什麼是最好的是很是複雜的。不要隨意使用你從別人那裏聽到的或者是你從以前一些項目中看到的。當心的決定對象仍是閉包更適合這個任務。

總結

本章的真理沒法被直述。必須閱讀本章來尋找它的真理。

【上一章】翻譯連載 | JavaScript輕量級函數式編程-第6章:值的不可變性 |《你不知道的JS》姊妹篇

iKcamp原創新書《移動Web前端高效開發實戰》已在亞馬遜、京東、噹噹開售。

>> 滬江Web前端上海團隊招聘【Web前端架構師】，有意者簡歷至：zhouyao@hujiang.com <<