java8 函數(shù)式編程

我最近一直在研究Java 8，并掌握了Manning出版的“ Java 8 In Action” 。 讓我印象深刻的第一件事是Java 8獨特的銷售主張是函數(shù)式編程。 函數(shù)現(xiàn)在是一流的變量，您可以像int或String一樣在代碼中傳遞它們。 這是一個很大的變化。

近年來，功能語言似乎變得越來越流行，并且它們沒有盡頭可供選擇。 現(xiàn)代函數(shù)式編程語言的例子包括Clojure，JavaScript，Scala，甚至是1980年代后期發(fā)明的Erlang都重新流行了。

那么，為什么會有這種方向變化？ 您可能會提出幾個原因，但我們首先要假設(shè)行業(yè)最佳實踐會隨著時間的推移而變化，甚至最流行的語言也有一天會不受歡迎。 我想如果您還年輕，就會有一天回頭說“記得我們曾經(jīng)使用Java的時候”嗎？ 在探討為什么會有這種變化之前，讓我們回顧一下1980年代到這里的方式……

根據(jù)Wikipedia的說法，IBM PC于1981年8月12日發(fā)布。第一批PC配備了BASIC ^1，盡管帥哥很快對此感到厭倦，并轉(zhuǎn)而使用Borland的Turbo Pascal。 Turbo Pascal的冷靜并沒有持續(xù)太久，因為微軟收購了Microsoft C（或MSC），后者很快成為事實上的標準。 這很酷，因為如果您很聰明，則可以使用int 21H ， int 10H和int 14h以及其他int 10H直接訪問硬件，并且如果可以記住哪個中斷做了什么，那么您就和我一樣老² …

IBM PC之前還有其他計算機，包括Apple II，Commodore Pet等，但是IBM PC是用于商業(yè)應用程序的“成熟” PC。 我記得我曾嘗試為我在1985年所做的一個項目購買一個，價格為數(shù)千英鎊，而您卻無法以愛情或金錢買到一個，每個人都想要一個。 但是，我離題了。

在1980年代后期，出現(xiàn)了Microsoft Windows SDK，這是一個基于C的SDK，自從平鋪Windows 1以來就出現(xiàn)了（顯然，Microsoft在Windows 1中沒有使用重疊的窗口，因為它復制了Apple的Macintosh并可能侵犯了他們的專利-盡管據(jù)稱Apple竊取了Xerox Parc對于Mac的想法，不過我不確定這是多么真實）。 該SDK確實在Windows 2中盛行，將世界引入了基于消息的回調(diào)程序； 據(jù)稱，他們從Unix的X-Windows和Motif竊取了一個想法。

在1990年代中期左右語言成為面向?qū)ο蟮?; 發(fā)明了類來將方法和數(shù)據(jù)聯(lián)系在一起，引入了數(shù)據(jù)隱藏和封裝的概念。 “ C”變成“ C ++”，如果此時您使用的是Windows SDK，那么您將切換到Microsoft基礎(chǔ)類。 SDK的OO包裝。 這種變化被視為一件好事。 舊的基于函數(shù)的語言的一個主要問題是，您可以在代碼庫中的任何位置分配全局變量，然后隨時使用任何函數(shù)對其進行更改。 顯然，這在很多系統(tǒng)中造成了重大問題，因為您不確定更改全局變量的狀態(tài)不會在應用程序的某個遙遠角落引入錯誤。 事實語言C的另一個主要問題是您負責分配和釋放內(nèi)存，并且如果內(nèi)存指針是全局的，那么在訪問它們時，您不能100％地確定該指針仍然有效，如果不是， t ...你墜毀了。

伴隨著面向?qū)ο蟮恼Z言出現(xiàn)了面向?qū)ο蟮姆椒ㄕ?#xff0c;并在1990年代后期使用UML達到了頂點。 這是Booch方法 ， James Rumbaugh的 OMT和Ivor Jacobsen的 OOSE的融合，并且在設(shè)計軟件時是必不可少的。 各種各樣的工具都可以用來記錄和傳達您的設(shè)計，而從經(jīng)驗來看，其中一些工具的質(zhì)量非?？梢?#xff0c;這就引出了一個問題：開發(fā)人員是否真的在使用UML編寫他們的UML程序？ 如果是這樣，那么這些產(chǎn)品對于UML來說并不是一個好廣告。

如今，您沒有看到使用UML的組織那么多，盡管當我需要直截了當設(shè)計時，我仍然會這樣做。 我的UML工具的首選是并且永遠是鉛筆和紙 。 這很簡單，而且有效。

最后，在我的編程簡要歷史中，最后是Java。 Java最初于1995年發(fā)布，幾年后開始流行，它基于改進C ++的思想。 這主要是因為它運行在自己的虛擬機上，該虛擬機負責您的內(nèi)存分配和釋放。 它已成為面向?qū)ο笳Z言的事實上的標準。

關(guān)于這個大致組成的時間表的事情是命令式編程的基本概念。 總而言之，匯編語言產(chǎn)生了C，C導致了C ++和OO，而C ++和OO導致了Java –所有這些都是必須的。 Wikipedia很好地概述了命令式編程，因此我不會對其進行詳細介紹，但我將命令式編程概括為具有函數(shù)和可變狀態(tài)的編程，這意味著您可以擁有實例變量和全局變量。

函數(shù)式編程與命令式編程有何不同？ 主要思想是函數(shù)是數(shù)據(jù)，就像整數(shù)和字符串一樣。 算法是根據(jù)函數(shù)調(diào)用實現(xiàn)的（ while不存在for循環(huán)，而使用遞歸），并且變量始終是局部的。

您可能會誤以為，因為它們包含函數(shù)的概念并且沒有類，所以諸如C和Turbo Pascal之類的語言都是函數(shù)式編程語言。 它們不是，它們是命令式編程語言，因為它們具有狀態(tài)數(shù)據(jù)。

那么，有什么變化？ 常見的答案是硬件發(fā)生了變化，這是由Erlang開發(fā)人員提出的，而在Manning的Java 8書中可以找到。 “計算機”（至少在服務器機房中可以找到）是一種復雜的多處理器，多核事務，具有TB級的內(nèi)存。 以HP Proliant DL580 G8服務器為例； 它最多具有四個處理器，每個處理器最多可以具有15個64位內(nèi)核。 這是巨大的，特別是與原始IBM PC上具有革命性的原始16位Intel 8086相比。 假設(shè)您正在運行Unix，并且運行了top命令，那么最大處理器使用率將為6000％。 鑒于機器功能的急劇增長，我們的軟件開發(fā)人員需要能夠支持它們的語言，從而使我們能夠輕松地使用所有這些并發(fā)處理能力，而這正是功能編程的出現(xiàn)。

在命令式編程中，您可以具有實例變量，全局變量和可變狀態(tài)。 盡管共享這些資源在同步和鎖定方面既昂貴又效率低下，但是它們可以在線程之間共享。 由于必須避免死鎖和其他類似問題，因此這樣做也相當緩慢且困難。 函數(shù)式編程消除了所有這些問題，因為它消除了實例變量和狀態(tài)的所有繁瑣處理。 這意味著您不必費心進行鎖定和同步，線程或進程（隨便稱它們）可以彼此獨立。

那是理論，但是它可以接受審查嗎？ 別忘了，有可能編寫出良好的多線程程序，這些程序可以有效地使用具有命令性Java 6或7的大型多核和多處理器計算機的許多內(nèi)核。就像函數(shù)式編程語言一樣，您也必須考慮一下自己所要做的事情。為此，請規(guī)劃合適的設(shè)計并使用業(yè)務“最佳實踐”執(zhí)行它。 僅僅因為Java 6或7是命令性語言，您不必在線程/進程之間共享數(shù)據(jù)，也不必使用同步和鎖定，這只是設(shè)計問題。 邏輯上的結(jié)論是，您可以不使用函數(shù)式編程而做，這可能導致函數(shù)式編程語言流行的真正原因：人們喜歡使用它們。

因此，您可以說功能語言是“最新的東西”。 狂熱，他們是新潮，一種時尚。 我必須強調(diào)，軟件開發(fā)中的“時尚”不一定是一件壞事，也不是什么新鮮事。 如果您回到上面的歷史，您會發(fā)現(xiàn)時間軸上充滿了趨勢和瘋狂：Turbo Pascal和BASIC上采用了“ C”，范式轉(zhuǎn)移到了Object Orientation，甚至是通過Java轉(zhuǎn)移到Java它只需編譯一次即可在任何地方運行。

您必須學習Java 8的函數(shù)式編程嗎？ 幾年后問我...

¹由于我記憶猶新，因此確保此博客中的所有歷史事實都不準確。
²如果我錯了，請糾正我，但是int 21H = MSDOS函數(shù)， int 10H =直接屏幕訪問， int 14H =串行I / O

翻譯自: https://www.javacodegeeks.com/2014/05/is-it-imperative-that-you-learn-functional-programming-with-java-8.html

java8 函數(shù)式編程

總結(jié)

以上是生活随笔為你收集整理的java8 函数式编程_您必须学习Java 8的函数式编程吗？的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。