怎么理解函數式編程思維?
當前位置:點晴教程→知識管理交流
→『 技術文檔交流 』
理解函數式編程要注重思維的轉變。函數式編程聚焦于簡潔的高階函數,高階函數注重封裝底層運作原理來解決復雜的業務場景,比如 Scala、Groovy、Clojure 語言:
1. 靜態類型必須先指定變量和函數的類型,而動態類型則允許推遲指定類型。強類型的變量“知道”自己的類型,允許反射和對實例作類型測試,且一直保有自身的類型信息。弱類型的語言相對不了解變量所指向的內容。 2. 命令式告訴計算機執行的步驟,一步一步告訴它怎么做。函數式更注重“做什么”本身,函數式編程是面向數學的抽象,函數式的代碼里只有函數和數據。 函數式編程提供以下幾個特性,讓開發拋開細節,投入到更高的抽象工作中:
函數式語言的重用表現在函數的通用性上,它們鼓勵在數據結構上使用各種共通的變換,并通過高階函數來調整操作以滿足具體事項的要求。比如函數式編程語言用一組關鍵數據結構(如 list、 set、map)來搭配專為這些數據結構深度優化過的操作,基于這些關鍵數據結構和操作組成的一套運轉機構上面,按需要“插入”另外的數據結構和高階函數來調整機器來解決具體的問題。再比如函數式編程語言提供了如 Either 類、Option 類來優化異常處理問題等。 在模式與重用方面,Java 提供了經典的 23 種設計模式來解決復雜的業務問題,函數式編程讓這些設計模式有了三種歸宿:
現實應用方面,Java8 提供了基于 lamda 表達式的函數式編程,但 Java 非函數式編程語言,Java 將問題域封裝在對象之內,并允許通過業務操作來改變對象的狀態,完全與函數式編程“變量無狀態”的思想背道而馳。那么函數式編程能應用于企業級需求解決方案嗎?從另一個角度來思考,Java 是面向對象的的編程語言,領域驅動設計(DDD)是面對企業級需求的解決方案,DDD 的戰術設計趨向于 CQRS 架構,而基于“變量不可變”的特性的函數式編程把 CQRS 架構作為基礎設施,所以能把函數式編程視為企業級需求的解決方案嗎?很明顯不能,DDD注重模擬現實世界,函數式編程思維并沒有試圖模擬現實世界,所以無法滿足復雜的企業需求,函數式編程大處理大量數據方面比面向對象方式更具有效率,正解是:面向對象編程是解決企業級需求的解決方案,解決過程中會產出大量的數據需求,可借力函數式編程。另外,《函數式編程思維》作者提到多范式語言組合才是趨勢,這一點很認同,未來語言必是混合的。編程語言是我們在計算機世界里解決問題的工具,函數式更注重What,而命令式更注重How。對于解決問題的能力,沒有高低強弱之分,只是角度和工具不同而已。 附《函數式編程思維》讀書筆記:
該文章在 2023/10/25 9:52:04 編輯過 |
關鍵字查詢
相關文章
正在查詢... |