JS中的柯里化及精巧的自動柯里化實現
什么是柯里化?
在計算機科學中,柯里化(Currying)是把接受多個參數的函數變換成接受一個單一參數(最初函數的***個參數)的函數,并且返回接受余下的參數且返回結果的新函數的技術。這個技術由 Christopher Strachey 以邏輯學家 Haskell Curry 命名的,盡管它是 Moses Schnfinkel 和 Gottlob Frege 發明的。
理論看著頭大?沒關系,先看看代碼:
柯里化應用
假設我們需要實現一個對列表元素進行某種處理的功能,比如說讓列表內每一個元素加一,那么很容易想到:
- const list = [0, 1, 2, 3];
- list.map(elem => elem + 1);
很簡單是吧?如果又要加2呢?
- const list = [0, 1, 2, 3];
- list.map(elem => elem + 1);
- list.map(elem => elem + 2);
看上去效率有點低,處理函數封裝下?
可是map的回調函數只接受當前元素 elem 這一個參數,看上去好像沒有辦法封裝...
你也許會想:如果能拿到一個部分配置好的函數就好了,比如說:
- // plus返回部分配置好的函數
- const plus1 = plus(1);
- const plus2 = plus(2);
- plus1(5); // => 6
- plus2(7); // => 9
把這樣的函數傳進map:
- const list = [0, 1, 2, 3];
- list.map(plus1); // => [1, 2, 3, 4]
- list.map(plus2); // => [2, 3, 4, 5]
是不是很棒棒?這樣一來不管是加多少,只需要list.map(plus(x))
就好了,***實現了封裝,可讀性大大提高! (☆゚∀゚)
不過問題來了:
這樣的plus函數要怎么實現呢?
這時候柯里化就能派上用場了:
柯里化函數
- // 原始的加法函數
- function origPlus(a, b) {
- return a + b;
- }
- // 柯里化后的plus函數
- function plus(a) {
- return function(b) {
- return a + b;
- }
- }
- // ES6寫法
- const plus = a => b => a + b;
可以看到,柯里化的 plus 函數首先接受一個參數 a,然后返回一個接受一個參數 b 的函數,由于閉包的原因,返回的函數可以訪問到父函數的參數 a,所以舉個例子:const plus2 = plus(2)
就可等效視為function plus2(b) { return 2 + b; }
,這樣就實現了部分配置。
通俗地講,柯里化就是一個部分配置多參數函數的過程,每一步都返回一個接受單個參數的部分配置好的函數。一些極端的情況可能需要分很多次來部分配置一個函數,比如說多次相加:
- multiPlus(1)(2)(3); // => 6
這種寫法看著很奇怪吧?不過如果入了JS的函數式編程這個大坑的話,這會是常態。(笑)
JS中自動柯里化的精巧實現
柯里化(Currying)是函數式編程中很重要的一環,很多函數式語言(eg. Haskell)都會默認將函數自動柯里化。然而JS并不會這樣,因此我們需要自己來實現自動柯里化的函數。
先上代碼:
- // ES5
- function curry(fn) {
- function _c(restNum, argsList) {
- return restNum === 0 ?
- fn.apply(null, argsList) :
- function(x) {
- return _c(restNum - 1, argsList.concat(x));
- };
- }
- return _c(fn.length, []);
- }
- // ES6
- const curry = fn => {
- const _c = (restNum, argsList) => restNum === 0 ?
- fn(...argsList) : x => _c(restNum - 1, [...argsList, x]);
- return _c(fn.length, []);
- }
- /***************** 使用 *********************/
- var plus = curry(function(a, b) {
- return a + b;
- });
- // ES6
- const plus = curry((a, b) => a + b);
- plus(2)(4); // => 6
這樣就實現了自動的柯里化!(╭ ̄3 ̄)╭♡
如果你看得懂發生了什么的話,那么恭喜你!大家口中的大佬就是你!╰(°▽°)╯,快留下贊然后去開始你的函數式生涯吧(滑稽
如果你沒看懂發生了什么,別擔心,我現在開始幫你理一下思路。
需求分析
我們需要一個 curry 函數,它接受一個待柯里化的函數為參數,返回一個用于接收一個參數的函數,接收到的參數放到一個列表中,當參數數量足夠時,執行原函數并返回結果。
實現方式
簡單思考可以知道,柯里化部分配置函數的步驟數等于 fn 的參數個數,也就是說有兩個參數的 plus 函數需要分兩步來部分配置。函數的參數個數可以通過fn.length
獲取。
總的想法就是每傳一次參,就把該參數放入一個參數列表 argsList 中,如果已經沒有要傳的參數了,那么就調用fn.apply(null, argsList)
將原函數執行。要實現這點,我們就需要一個內部的判斷函數 _c(restNum, argsList),函數接受兩個參數,一個是剩余參數個數 restNum,另一個是已獲取的參數的列表 argsList;_c 的功能就是判斷是否還有未傳入的參數,當 restNum 為零時,就是時候通過fn.apply(null, argsList)
執行原函數并返回結果了。如果還有參數需要傳遞的話,也就是說 restNum 不為零時,就需要返回一個單參數函數
- function(x) {
- return _c(restNum - 1, argsList.concat(x));
- }
來繼續接收參數。這里形成了一個尾遞歸,函數接受了一個參數后,剩余需要參數數量 restNum 減一,并將新參數 x 加入 argsList 后傳入 _c 進行遞歸調用。結果就是,當參數數量不足時,返回負責接收新參數的單參數函數,當參數夠了時,就調用原函數并返回。
現在再來看:
- function curry(fn) {
- function _c(restNum, argsList) {
- return restNum === 0 ?
- fn.apply(null, argsList) :
- function(x) {
- return _c(restNum - 1, argsList.concat(x));
- };
- }
- return _c(fn.length, []); // 遞歸開始
- }
是不是開始清晰起來了? (゚▽゚)
ES6寫法的由于使用了 數組解構 及 箭頭函數 等語法糖,看上去精簡很多,不過思想都是一樣的啦~
- // ES6
- const curry = fn => {
- const _c = (restNum, argsList) => restNum === 0 ?
- fn(...argsList) : x => _c(restNum - 1, [...argsList, x]);
- return _c(fn.length, []);
- }
與其他方法的對比
還有一種大家常用的方法:
- function curry(fn) {
- const len = fn.length;
- return function judge(...args1) {
- return args1.length >= len ?
- fn(...args1):
- function(...args2) {
- return judge(...[...args1, ...args2]);
- }
- }
- }
- // 使用箭頭函數
- const curry = fn => {
- const len = fn.length;
- const judge = (...args1) => args1.length >= len ?
- fn(...args1) : (...args2) => judge(...[...args1, ...args2]);
- return judge;
- }
與本篇文章先前提到的方法對比的話,發現這種方法有兩個問題:
-
依賴ES6的解構(函數參數中的 ...args1 與 ...args2);
-
性能稍差一點。
性能問題
做個測試:
- console.time("curry");
- const plus = curry((a, b, c, d, e) => a + b + c + d + e);
- plus(1)(2)(3)(4)(5);
- console.timeEnd("curry");
在我的電腦(Manjaro Linux,Intel Xeon E5 2665,32GB DDR3 四通道1333Mhz,Node.js 9.2.0)上:
-
本篇提到的方法耗時約 0.325ms
-
其他方法的耗時約 0.345ms
差的這一點猜測是閉包的原因。由于閉包的訪問比較耗性能,而這種方式形成了兩個閉包:fn 和 len,前面提到的方法只形成了 fn 一個閉包,所以造成了這一微小的差距。
也希望大家能自己測試下并說說自己的看法~