JavaScript函數式編程(一)

引言

說到函數式編程,大家可能第一印象都是學院派的那些晦澀難懂的代碼,充滿了一大堆抽象的不知所云的符號,似乎只有大學裡的計算機教授才會使用這些東西。在曾經的某個時代可能確實如此,但是近年來隨著技術的發展,函數式編程已經在實際生產中發揮巨大的作用了,越來越多的語言開始加入閉包,匿名函數等非常典型的函數式編程的特性,從某種程度上來講,函數式編程正在逐步“同化”命令式編程。

JavaScript 作為一種典型的多範式編程語言,這兩年隨著React的火熱,函數式編程的概念也開始流行起來。


純函數

如果你還記得一些初中的數學知識的話,函數 f 的概念就是,對於輸入 x 產生一個輸出 y = f(x)。這便是一種最簡單的純函數。

純函數的定義是,對於相同的輸入,永遠會得到相同的輸出,而且沒有任何可觀察的副作用,也不依賴外部環境的狀態。

下面來舉個栗子,比如在Javascript中對於數組的操作,有些是純的,有些就不是純的:

JavaScript函數式編程(一)

在函數式編程中,我們想要的是 slice 這樣的純函數,而不是 splice這種每次調用後都會把數據弄得一團亂的函數。

為什麼函數式編程會排斥不純的函數呢?下面再看一個例子:

JavaScript函數式編程(一)

在不純的版本中,checkage 這個函數的行為不僅取決於輸入的參數 age,還取決於一個外部的變量 min,換句話說,這個函數的行為需要由外部的系統環境決定。對於大型系統來說,這種對於外部狀態的依賴是造成系統複雜性大大提高的主要原因。

可以注意到,純的 checkage 把關鍵數字 18 硬編碼在函數內部,擴展性比較差,我們可以在後面的柯里化中看到如何用優雅的函數式解決這種問題。

純函數不僅可以有效降低系統的複雜度,還有很多很棒的特性,比如可緩存性:

JavaScript函數式編程(一)


函數的柯里化

函數柯里化(curry)的定義很簡單:傳遞給函數一部分參數來調用它,讓它返回一個函數去處理剩下的參數。

比如對於加法函數 var add = (x, y) => x + y ,我們可以這樣進行柯里化:

JavaScript函數式編程(一)

對於加法這種極其簡單的函數來說,柯里化並沒有什麼大用處。

還記得上面那個 checkage 的函數嗎?我們可以這樣柯里化它:

var checkage = min => (age => age > min);
var checkage18 = checkage(18);
checkage18(20);
// =>true

事實上柯里化是一種“預加載”函數的方法,通過傳遞較少的參數,得到一個已經記住了這些參數的新函數,某種意義上講,這是一種對參數的“緩存”,是一種非常高效的編寫函數的方法:

JavaScript函數式編程(一)


函數組合

學會了使用純函數以及如何把它柯里化之後,我們會很容易寫出這樣的“包菜式”代碼:

h(g(f(x)));

雖然這也是函數式的代碼,但它依然存在某種意義上的“不優雅”。為了解決函數嵌套的問題,我們需要用到“函數組合”:

JavaScript函數式編程(一)

我們定義的compose就像雙面膠一樣,可以把任何兩個純函數結合到一起。當然你也可以擴展出組合三個函數的“三面膠”,甚至“四面膠”“N面膠”。

這種靈活的組合可以讓我們像拼積木一樣來組合函數式的代碼:

JavaScript函數式編程(一)


Point Free

有了柯里化和函數組合的基礎知識,下面介紹一下Point Free這種代碼風格。

細心的話你可能會注意到,之前的代碼中我們總是喜歡把一些對象自帶的方法轉化成純函數:

var map = (f, arr) => arr.map(f);
var toUpperCase = word => word.toUpperCase();

Point Free這種模式現在還暫且沒有中文的翻譯,用中文解釋的話大概就是,不要命名轉瞬即逝的中間變量,比如:

//這不Piont free
var f = str => str.toUpperCase().split(' ');

這個函數中,我們使用了 str 作為我們的中間變量,但這個中間變量除了讓代碼變得長了一點以外是毫無意義的。下面改造一下這段代碼:

JavaScript函數式編程(一)

這種風格能夠幫助我們減少不必要的命名,讓代碼保持簡潔和通用。當然,為了在一些函數中寫出Point Free的風格,在代碼的其它地方必然是不那麼Point Free的,這個地方需要自己取捨。


命令式代碼的意思就是,我們通過編寫一條又一條指令去讓計算機執行一些動作,這其中一般都會涉及到很多繁雜的細節。

而聲明式就要優雅很多了,我們通過寫表達式的方式來聲明我們想幹什麼,而不是通過一步一步的指示。

JavaScript函數式編程(一)

命令式的寫法要先實例化一個數組,然後再對 companies 數組進行for循環遍歷,手動命名、判斷、增加計數器,就好像你開了一輛零件全部暴露在外的汽車一樣,雖然很機械朋克風,但這並不是優雅的程序員應該做的。

聲明式的寫法是一個表達式,如何進行計數器迭代,返回的數組如何收集,這些細節都隱藏了起來。它指明的是做什麼,而不是怎麼做。除了更加清晰和簡潔之外,map 函數還可以進一步獨立優化,甚至用解釋器內置的速度極快的 map 函數,這麼一來我們主要的業務代碼就無須改動了。

函數式編程的一個明顯的好處就是這種聲明式的代碼,對於無副作用的純函數,我們完全可以不考慮函數內部是如何實現的,專注於編寫業務代碼。優化代碼時,目光只需要集中在這些穩定堅固的函數內部即可。

相反,不純的不函數式的代碼會產生副作用或者依賴外部系統環境,使用它們的時候總是要考慮這些不乾淨的副作用。在複雜的系統中,這對於程序員的心智來說是極大的負擔。


尾聲

任何代碼都是要有實際用處才有意義,對於JS來說也是如此。然而現實的編程世界顯然不如範例中的函數式世界那麼美好,實際應用中的JS是要接觸到ajax、DOM操作,NodeJS環境中讀寫文件、網絡操作這些對於外部環境強依賴,有明顯副作用的“很髒”的工作。

這對於函數式編程來說也是很大的挑戰,所以我們也需要更強大的技術去解決這些“髒問題”。我會在下一篇文章中介紹函數式編程的更加高階一些的知識,例如Functor、Monad等等概念。


分享到:


相關文章: