摘要：前面一段時間對和兩者的關(guān)系感到比較困惑我使用的動態(tài)語言揉合太多范式在這一點上很難做出明確透徹的區(qū)分不過經(jīng)過這段時間琢磨相對之前感覺要好一些了有了一些自己的想法后面自己的部分會有不少沒有驗證的地方所以應(yīng)該當(dāng)成感想來看需要說明我的經(jīng)驗來自動態(tài)語

前面一段時間對 FP 和 OOP 兩者的關(guān)系感到比較困惑
我使用的動態(tài)語言揉合太多范式, 在這一點上很難做出明確透徹的區(qū)分
不過經(jīng)過這段時間琢磨相對之前感覺要好一些了, 有了一些自己的想法
后面自己的部分會有不少沒有驗證的地方, 所以應(yīng)該當(dāng)成感想來看
需要說明, 我的經(jīng)驗來自動態(tài)語言(JavaScript), 相對靜態(tài)語言會有很多紕漏

當(dāng)然這種事情先 Google 是必需的, 我當(dāng)時微博標(biāo)記了兩份比較在意的說明:

Functional programming vs Object Oriented programming

我摘錄的原文部分應(yīng)該很有建設(shè)性, 就不翻譯了:

  
When you anticipate a different kind of software evolution:

  
Object-oriented languages are good when you have a fixed set of operations on things, and as your code evolves, you primarily add new things. This can be accomplished by adding new classes which implement existing methods, and the existing classes are left alone.
  

  
Functional languages are good when you have a fixed set of things, and as your code evolves, you primarily add new operations on existing things. This can be accomplished by adding new functions which compute with existing data types, and the existing functions are left alone.
  

  
When evolution goes the wrong way, you have problems:

  
Adding a new operation to an object-oriented program may require editing many class definitions to add a new method.
  

  
Adding a new kind of thing to a functional program may require editing many function definitions to add a new case.
  

根據(jù)估計的未來代碼中是數(shù)據(jù)或者是操作為主, 會有一定的區(qū)分
面向?qū)ο筮m合在新系統(tǒng)中接入新的數(shù)據(jù), 函數(shù)式適合在原有代碼上增加新的方法

我覺得上邊說的 functional 和純函數(shù)的編程可能還有差別..
另一份實在 Haskell 的 Wiki 上,

The Monad.Reader/Issue3/Functional Programming vs Object Oriented Programming

這里摘錄的是在文章當(dāng)中的一個引用:

  
To quote:

  
    
"The functional approach to programming is to ask "how is data constructed?". This leads to a style of programming where the data constructors are considered primitive, and where data-consuming code accordingly is defined by pattern-matching over these constructors. The object-oriented programmer instead starts out by asking "what can we do with the data?", which fosters the view that it is the data selectors that should be seen as foundational, and that the code of a data-producer consequently should be defined as an enumeration of implementations for these selectors."
  

  
What"s telling is the description of the effects (local and non-local) of different types of modification to the program:

  
    
"The functional style ensures that adding another data-consumer (a function) is a strictly local change, whereas adding a new data-producer requires extending a datatype with a new constructor, and thus a major overhaul of every pattern-matching function definition. Likewise, in object-oriented programming the addition of a new data-producer (a new class) is a cinch, while the introduction of another data-consumer means the extension of a record type with a new selector, a global undertaking with implications to potentially all existing classes."
  

不是完全理解, 大義應(yīng)該有很多相似的地方,
FP 中數(shù)據(jù)類型是根基, 很容易增加數(shù)據(jù)操作, 增加數(shù)據(jù)類型需要大范圍調(diào)整
面向?qū)ο螽?dāng)中定義數(shù)據(jù)應(yīng)有的操作, 增加操作會影響到大量數(shù)據(jù)擁有的方法(?)

麻煩的是在動態(tài)語言當(dāng)中沒有 Java 也沒有 Haskell 那么多限制, 并不明確
所以看了上邊的解釋, 我其實還是有些糊涂, 雖然是我看到最明確的版本了
不過, immutable 那些特性可不是在這里邊講的,

Functional Programming Patterns (BuildStuff "14)

另外還有一份 FP 的資料, 只看到 slide, 沒找到視頻
其中一張挺有意思, 就是 OOP 里各種范式, FP 都用函數(shù)解決掉了

我想說是的, 困惑我的, 是 FP 和 OOP 在思維方式上的巨大差別
而隱藏在后邊的 immutable 特性, 在開始的時候更讓我困惑
后面就開始說我的困惑和理解吧(確實網(wǎng)上的內(nèi)容我沒有理解透徹)

FP 和 OOP 不是截然對立的思維, 在編寫中實際上和經(jīng)常相互滲透
OOP 當(dāng)中, 比如動態(tài)語言隨時可能插入 FP 的 List 操作方法
而 FP 當(dāng)中, 也可能模擬 OOP 對數(shù)據(jù)封裝和抽象(網(wǎng)上看到 Scheme 有例子, 不熟悉)
在 FP 當(dāng)中, 很重要的概念是 Composable 和 Purity(可復(fù)合, 沒有副作用)
但 OOP 當(dāng)中并不是不允許組合操作和避免副作用, 同時這些是編程貫穿的主題
Node 腳本的代碼, 模塊化, 減少依賴, 建立在 OOP 之上, 說法和 FP 并沒有太大區(qū)別
所以單純在用法上的區(qū)別, 我任務(wù)應(yīng)該是由更為基本的規(guī)則引起的

加上排除語法, 排除類型, 我還是覺得 immutability 是最為重要的差別
換句話說, 一個名字, 或者參數(shù)一致的函數(shù), 每次調(diào)用的結(jié)果是否完全一樣
FP 做了這樣的限定, 導(dǎo)致編碼的難度上升, 需要模擬每次操作后狀態(tài)的改變
在 FP 中, 就是生成一份新的數(shù)據(jù), 通過高階函數(shù), 模擬對同一個名字進行操作
但是首先, 共享變量名來進行消息傳遞這一點變得挺困難(或者說特殊)了

在 OOP 當(dāng)中, 我們期待把大的問題拆解成幾個小的模塊分別解決
比如說, 為每個過程設(shè)定一些數(shù)據(jù), 封裝然后暴露一些接口, 出來
最終模塊直接通過調(diào)用接口, 相互發(fā)送接受消息獨立完成工作, 完成整個任務(wù)
考慮數(shù)據(jù) immutable 的話, 每個模塊內(nèi)部狀態(tài)就不能實現(xiàn)了
那么這部分狀態(tài)將被提取出來放到全局, 再作為參數(shù)傳回到模塊當(dāng)中
這時的模塊更像是 pipe 的概念, 整個程序的運行就是在管道當(dāng)中流動
一個好處是數(shù)據(jù)不再像 OOP 那樣存在多份, 需要設(shè)計機制去同步

后面是最近我在思考 Cumulo 實現(xiàn)的過程考慮到的和想到的問題
這是我第一次拋開框架寫后端代碼, 剛一開始被怎樣組織代碼所困擾
困擾之后我還是用 mutable 數(shù)據(jù)還消息來勾勒整個消息傳播的方案
嘗試之后我采用一個架構(gòu)圖描繪了數(shù)據(jù)怎樣在這個程序當(dāng)中流動

也許我可以這樣思考程序, 將程序劃分為幾塊, 分別對應(yīng)功能:

數(shù)據(jù)結(jié)構(gòu), 初始的資源和狀態(tài) --> 這是一個適合機器的形態(tài)

交互的界面 --> 數(shù)據(jù)結(jié)構(gòu)轉(zhuǎn)化為適合人類編寫, 調(diào)試, 查看, 交互的形態(tài)

業(yè)務(wù)邏輯 --> 決定數(shù)據(jù)怎樣改變的操作的規(guī)則

架構(gòu) --> 操作或者事件, 怎樣正確有效更新整個程序范圍的資源和狀態(tài)

程序越大, 思考架構(gòu)越發(fā)困難, 特別是要照顧好多的細節(jié), 細節(jié)相互沖突
簡化來說, OOP 似乎很容易想采用消息, 讓每個模塊以監(jiān)聽的方式更新和同步
而在 FP, 沒有消息, 轉(zhuǎn)而采用定向的數(shù)據(jù)流動, 逐個地想做系統(tǒng)狀態(tài)進行更新
現(xiàn)在我了解的, OOP 操作簡單, 可是當(dāng)模塊繁多, 容易造成節(jié)奏紊亂, 難于調(diào)試
FP 則是不容易設(shè)計實現(xiàn), 現(xiàn)實世界狀態(tài)凌亂, 難以符合單向流的形式

另外我也注意到, 就是在微博上發(fā)的那條感想:

  
最近想起王垠那個比喻, 可變數(shù)據(jù)像 WIFI, 不可變數(shù)據(jù)像線, WIFI 方便多了. 可是從另一個角度看 WIFI 是短距離穩(wěn)定, 遠了信號差, 線麻煩是麻煩, 遠距離傳輸損耗小(也不能普通網(wǎng)線...). 可變數(shù)據(jù)不用面向?qū)ο竽菢臃庋b在局部進行控制, 變量多了真心容易亂. 不可變數(shù)據(jù)呢門檻又高..

mutable 數(shù)據(jù), 如果被反復(fù)轉(zhuǎn)發(fā)傳送, 很可能會在某些操作當(dāng)中被更改
當(dāng)數(shù)據(jù)容易發(fā)生難以預(yù)料的更改, 構(gòu)建大程序也就成了麻煩了
因此對于 mutable 數(shù)據(jù), 在本地進行封裝, 不直接對外暴露, 是極為合理的做法
這在 JavaScript 當(dāng)中, 對象被不斷引用共享, 直到出現(xiàn) bug, 是很可能發(fā)生的事情
那么思考大程序的話, mutable 數(shù)據(jù)是應(yīng)該盡量減少的方案

到目前為止, 我所能相對的構(gòu)建程序最讓我覺得建設(shè)性的是這個架構(gòu)圖
即便真心寫到?jīng)]思路了, 好歹還能照著圖用拙劣的代碼補上一些功能上去
對著 FP 和 OOP 這些爭論了許久的功能思考不清楚, 只能按著圖上瞎寫
希望能早點走出這篇迷霧吧..