# 第十三章 函數式編程 > 函數式編程語言操縱代碼片段就像操作數據一樣容易。 雖然 Java 不是函數式語言，但 Java 8 Lambda 表達式和方法引用 (Method References) 允許你以函數式編程。 在計算機時代早期，內存是稀缺和昂貴的。幾乎每個人都用匯編語言編程。人們雖然知道編譯器，但編譯器生成的代碼很低效，比手工編碼的匯編程序多很多字節，僅僅想到這一點，人們還是選擇匯編語言。 通常，為了使程序能在有限的內存上運行，在程序運行時，程序員通過修改內存中的代碼，使程序可以執行不同的操作，用這種方式來節省代碼空間。這種技術被稱為**自修改代碼**（self-modifying code）。只要程序小到幾個人就能夠維護所有棘手和難懂的匯編代碼，你就能讓程序運行起來。 隨著內存和處理器變得更便宜、更快。C 語言出現并被大多數匯編程序員認為更“高級”。人們發現使用 C 可以顯著提高生產力。同時，使用 C 創建自修改代碼仍然不難。 隨著硬件越來越便宜，程序的規模和復雜性都在增長。這一切只是讓程序工作變得困難。我們想方設法使代碼更加一致和易懂。使用純粹的自修改代碼造成的結果就是：我們很難確定程序在做什么。它也難以測試：除非你想一點點測試輸出，代碼轉換和修改等等過程？ 然而，使用代碼以某種方式操縱其他代碼的想法也很有趣，只要能保證它更安全。從代碼創建，維護和可靠性的角度來看，這個想法非常吸引人。我們不用從頭開始編寫大量代碼，而是從易于理解、充分測試及可靠的現有小塊開始，最后將它們組合在一起以創建新代碼。難道這不會讓我們更有效率，同時創造更健壯的代碼嗎？ 這就是**函數式編程**（FP）的意義所在。通過合并現有代碼來生成新功能而不是從頭開始編寫所有內容，我們可以更快地獲得更可靠的代碼。至少在某些情況下，這套理論似乎很有用。在這一過程中，函數式語言已經產生了優雅的語法，這些語法對于非函數式語言也適用。 你也可以這樣想： OO（object oriented，面向對象）是抽象數據，FP（functional programming，函數式編程）是抽象行為。 純粹的函數式語言在安全性方面更進一步。它強加了額外的約束，即所有數據必須是不可變的：設置一次，永不改變。將值傳遞給函數，該函數然后生成新值但從不修改自身外部的任何東西（包括其參數或該函數范圍之外的元素）。當強制執行此操作時，你知道任何錯誤都不是由所謂的副作用引起的，因為該函數僅創建并返回結果，而不是其他任何錯誤。 更好的是，“不可變對象和無副作用”范式解決了并發編程中最基本和最棘手的問題之一（當程序的某些部分同時在多個處理器上運行時）。這是可變共享狀態的問題，這意味著代碼的不同部分（在不同的處理器上運行）可以嘗試同時修改同一塊內存（誰贏了？沒人知道）。如果函數永遠不會修改現有值但只生成新值，則不會對內存產生爭用，這是純函數式語言的定義。 因此，經常提出純函數式語言作為并行編程的解決方案（還有其他可行的解決方案）。 需要提醒大家的是，函數式語言背后有很多動機，這意味著描述它們可能會有些混淆。它通常取決于各種觀點：為“并行編程”，“代碼可靠性”和“代碼創建和庫復用”。[^1](https://github.com/LingCoder/OnJava8/blob/master/docs/book/%E5%8A%9F%E8%83%BD%E7%B2%98%E8%B4%B4%E5%9C%A8%E4%B8%80%E8%B5%B7%E7%9A%84%E6%96%B9%E6%B3%95%E7%9A%84%E7%A1%AE%E6%9C%89%E7%82%B9%E4%B8%8E%E4%BC%97%E4%B8%8D%E5%90%8C%EF%BC%8C%E4%BD%86%E5%AE%83%E4%BB%8D%E4%B8%8D%E5%A4%B1%E4%B8%BA%E4%B8%80%E4%B8%AA%E5%BA%93%E3%80%82)關于函數式編程能高效創建更健壯的代碼這一觀點仍存在部分爭議。雖然已有一些好的范例\[^2\]，但還不足以證明純函數式語言就是解決編程問題的最佳方法。 FP 思想值得融入非 FP 語言，如 Python。Java 8 也從中吸收并支持了 FP。我們將在此章探討。