【前端開發】FP 基礎:純函式 & 柯里化

2022/11/21閱讀時間約 4 分鐘
Functional Programming 中文譯作函式程式設計,或是功能性程式設計,常簡稱為:FP,是一種透過使用純函式(Pure Funciton)進行軟體開發,且避免副作用的程式設計典範,比起宣告式的流程控制,在 FP 採用主要以表達式的方式撰寫程式碼。
如果我們將 FP 這個設計典範的特點一一列點出來會有以下概念:
  • 透過純函數(Pure Function)將函式封裝成函式最小單位
  • 使用複合函數(Function Composition)提升函式的復用性
  • 避免副作用(Side Effect)
  • 使用表達式
接著就讓我們來看看什麼是純函式吧!

什麼是純函式?

純函式(Pure Funciton)在 FP 中是一個很核心的概念,在 FP 這個設計典範中,我們都會使用純函式的方式來撰寫我們的程式碼。
首先讓我們來看看純函式的定義:
  • 單輸入單輸出(One input, one output)
  • 不會造成任何副作用
那我們為什麼在 FP 中要使用純函式呢?我們希望可以讓程式碼的狀態不互相依賴,以免造成變數與變數間互相覆蓋的狀況。
更重要的是,我們同時也希望程式碼的覆用性可以更高,而不是在同個函式中,同時處理不同性質的任務,一旦這些任務重複性出現在不同的流程中,就會發現任務彼此之間過於耦合難以拆分,要擴充新的功能,就只能向樂高一樣繼續往上疊,或一改就要改到天荒地老的窘境。
除了開發過程可能變得沒有效率外,把程式碼當樂高疊的後果是,萬一未來有人不小心改到了某個地方,就很容易導致這個程式碼樂高塔輕易崩塌。
在 FP 中,我們傾向把任務拆分成最小最小的單位,並且透過函式來處理這些任務,而規則單純卻又嚴謹的純函式就成為 FP 最萬用的工具。
如果我們要寫一個簡單、但卻會重複出現的篩選邏輯,例如:將指定商品進行打折,沒有使用 FP 前我們可能會這樣寫:
或者是:
上述這些程式碼會有幾個狀況:重複程式碼函式內一次性做太多事,如果我只要取得指定商品的打折價,就必須再計算一次,或是取得其他商品的打折數,這樣就很容易產生副作用,甚至是預期外的結果。
現在我們使用純函式寫一個打折器:
這樣是不是乾淨許多呢?除了純函式外,在 FP 中我們還會使用另外一個工具:「柯里化」來管理我們的程式碼。

什麼是「柯里化」?

其實最初科里化(Currying)是一個數學理論,後續才由 Haskell Curry 發揚光大,故名「Currying」。
科里化的核心概念是將函式要帶入的多個參數,轉換為一次性帶入一個參數,舉例來說:
這麼做有什麼好處呢?讓我們來看看科里化與純函式相比有什麼好處:
  1. 可以把程式法切的更碎片,提高複用性,例如:可以固定第一個、第 n 個參數的值,根據需求將關注點放在需要放的地方。
  2. 因為一次只傳入一個參數,降低傳入參數數量的錯誤
難道上述兩個優點純函式做不到嗎?是的純函式還真的做不到,讓我們直接來看範例比較:
我們會發現若是透過純函式固定第一個參數,其實沒什麼意義,因為我們還是會不斷重複帶入同樣的參數,光是上方的程式碼,就足以想見未來若是要重複使用函式,未經科里化的純函式程式碼會越來越多。
以上就是 FP 設計典範中最基礎也是最廣為人知的概念,不過 FP 的概念不僅僅於此,如果你有興趣的話,可以參考我在 2022 第十四屆 iThome 鐵人賽《致 JavaScript 開發者的 Functional Programming 新手指南》
在這系列文章中,除了介紹 Functional Programming 這門設計典範外,也包含了要習得 FP 技術前所必備的 JavaScript 基礎知識,及一些 FP 在前端的演進史。
希望透過這篇文章的分享,可以讓大家簡單了解那些前端開發者常說的 Pure Function 及 Curry 是什麼,關於 Functional Programming 你有什麼想要跟我分享的嗎?歡迎下方留言與我分享!
希望今天的文章有幫助到正在閱讀的你,如果你喜歡我的文章的話,可以留下你的愛心或是收藏我的文章,也或者可以點選「贊助」,你的一杯咖啡絕對是我持續寫下去的動力!或是透過拍拍手,用你小小的行動支持我的創作!
我是Vivian,我們下次見。
關於我:
一名從英文系畢業的前端工程師,喜歡閱讀、寫東西及自我成長。
|聯絡我:[email protected]
為了追求可以窩在座位上、可以心無旁騖思考問題、座位可以亂七八糟沒關係、不需要到處哈腰點頭跑客戶,不用腳踩十公分、連妝都可以不用化的職場人生,文組少女毅然決然踏上RD的養成日常。
留言0
查看全部
發表第一個留言支持創作者!