C++函數式編程（二）純函數

原文：http://www.altdevblogaday.com/2012/04/26/functional-programming-in-c/

作者：John Carmack

-潘宏 譯

-2013年1月

-email:
popyy@netease.com

-weibo.com/panhong101

純函數（Pure Function）與外界交換資料只有唯一渠道——參數和傳回值。其在邏輯上沒有副作用（譯註：副作用就是潛在地和函數的外部環境交換資料）——這當然只是從抽象角度來說。從現實角度講，任何函數在CPU層級上都存在副作用，大多數函數在堆層級上也有副作用。可就算有這些副作用，這種在邏輯層面上的抽象也是有意義的。

純函數不讀寫全域變數，無狀態、無IO，不改變傳入的任何參數。理想情況下，不會給他傳入任何外部資料，因為一旦傳入一個諸如allMyGlobals的指標，上面的這些規則就都被打破了。

純函數有諸多很棒的特性。

執行緒安全性。只有傳值參數的純函數是完全安全執行緒的。如果有引用或者指標類型的參數，就算是const類型的，你也得注意：另一個會執行non-pure操作的線程可能會改變或者釋放這些引用或者指標，這很危險。可是，即使在這種情況下存在隱患，純函數仍不失為一種安全編寫多線程程式的有力工具。

你可以輕易地將純函數應用於並行計算領域，或者多次計算然後比較結果。這種方式更易於對系統進行實驗和擴充。

重用性。很容易把一個純函數移植到一個新的運行環境。你可能仍然需要修改類型定義以及這些被調用純函數，但這不會引起滾雪球效應。而這種效應往往表現為：很多時候，你需要在另外一個系統中使用你之前的一些代碼，因此你得把那些代碼從原來的系統中提取出來，然後把它們融合進新的系統，可這個時候你發現，提取這些代碼比重寫一個還費事。

可測試性。純函數具有引用透明性（Referential Transparency）。也就是說，對於同一個輸入值，它一定產生相同的輸出值，而與什麼時候執行該函數無關。而其它一些和系統相互耦合的機制，與純函數相比，在測試的可操作性方面都遜色不少。此外，我本人從來都沒有非常負責任地編寫過測試代碼——那種在足夠多的系統上都跑過的，經過精心安排的測試。而且我竟然還會經常安慰自己（我錯了）：這種測試其實是沒必要的。但是，純函數卻很容易測試，就像教課書中所描述的：安排一些輸入，然後觀察輸出。現在，每當我遇到一些看起來比較複雜的代碼，我都會把它們剝離出來並放入一個單獨的純函數中，寫一些用例來測試它們。而令我感到驚恐的是，代碼經常會測出問題，我還真是想的不夠周全。

可理解性和可維護性。純函數在輸入輸出值上的限定性，讓長時間沒有接觸並對它們感到陌生的程式員，在需要的時候很容易回過頭來，重新理解它們。此外，一些涉及程式外部狀態的，沒有文檔記錄在案的需求，也已經被純函數本身的特性所杜絕。

形式系統（Formal Systems）和自動推理軟體（Automated Reasoning About Software）以後會越來越重要。而靜態程式碼分析（Static Code Analysis）目前已經很重要了，它會把程式轉化進更加函數式化的輔助分析工具，或者，至少能夠用快速的局部測試載入器代替低速的、昂貴的全域測試載入器，並保持相同的測試覆蓋面。我們正處於一個“任務導向型”產業之中，以“程式全部都正確”為目標我們還不敢奢望，能夠證明我們的程式碼程式庫中的關鍵區段都沒問題，在目前來看還是比較有現實意義的。在開發過程中，我們可以使用更科學嚴謹的方法。

某人面對著一個新手層級的程式樣本，可能會一邊撓頭一邊嘀咕：“是不是所有的程式都是這麼寫的？”。而現實情況往往就是這樣：存在著大量的“大泥球“（Big Balls of Mud，譯註：指沒有清晰結構的系統）。傳統程式設計語言給了開發人員各種各樣的文法甜頭，而且大家的態度就是能用就用。如果你覺得你寫的代碼是“一次性”的，那麼怎麼方便就怎麼來吧，你可能會大量使用全域變數。但如果你希望你的代碼一年後還能用，那就權衡一下，你現在的方便可能會變成你以後的痛苦。大多數開發人員都不太擅長預見自己將來因代碼修改而帶來的代碼整合痛苦。