[TOC] ### 面向對象編程（OOP）與面向函數編程（FOP） #### **面向對象編程（OOP）** **在OOP中，一切皆是對象**。 在面向對象的命令式（imperative）編程語言里面，構建整個世界的基礎是類和類之間溝通用的消息，這些都可以用類圖（class diagram）來表述。《設計模式：可復用面向對象軟件的基礎》（Design Patterns: Elements of Reusable Object-Oriented Software，作者ErichGamma、RichardHelm、Ralph Johnson、John Vlissides）一書中，在每一個模式的說明里都附上了至少一幅類圖。 **OOP 的世界提倡開發者針對具體問題建立專門的數據結構，相關的專門操作行為以“方法”的形式附加在數據結構上，自頂向下地來構建其編程世界**。 **OOP追求的是萬事萬物皆對象的理念，自然地弱化了函數**。例如：函數無法作為普通數據那樣來傳遞（OOP在函數指針上的約束），所以在OOP中有各種各樣的、五花八門的設計模式。 絕大部分設計模式的實現都離不開多態性的思想。換一種說法就是，這些設計模式背后的本質其實就是OOP的多態性，而OOP中的多態本質上又是受約束的函數指針。 很多設計模式，在函數式編程中都可以用高階函數來代替實現：  #### **面向函數編程（FOP）** 在FP中，一切皆是函數。 函數式編程（FP）是關于不變性和函數組合的一種編程范式。 **函數式編程語言實現重用的思路很不一樣。函數式語言提倡在有限的幾種關鍵數據結構（如list、set、map）上 ， 運用函數的組合 ( 高階函數) 操作，自底向上地來構建世界。** 當然，我們在工程實踐中，是不能極端地追求純函數式的編程的。一個簡單的原因就是：性能和效 率。純函數式編程是解決某些問題的偉大工具，但是在另外的一些問題場景中，并不適用。因為副作用總是真實存在。 **OOP喜歡自頂向下架構層層分解（解構），FP喜歡自底向上層層組合（復合）**。 而實際上，**編程的本質就是次化分解與復合的過程。通過這樣的過程，創造一個美妙的邏輯之塔世界**。 在OOP中，一個理想的對象應該是只暴露它的抽象接口（純表面， 無體積），其方法則扮演箭頭的角色。如果為了理解一個對象如何與其他對象進行復合，當你發現不得不深入挖掘對象的實現之 時，此時你所用的編程范式的原本優勢就蕩然無存了。 FP通過函數組合來構造其邏輯系統。FP傾向于把軟件分解為其需要執行的行為或操作,而且通常采用自底向上的方法。函數式編程也提供了非常強大的對事物進行抽象和組合的能力。 在FP里面，函數是“一類公民”（first-class）。它們可以像1, 2, "hello"，true，對象…… 之類的“值”一樣，在任意位置誕生，通過變量，參數和數據結構傳遞到其它地方，可以在任何位置被調用。 而在OOP中，很多所謂面向對象設計模式（design pattern），都是因為面向對象語言沒有firstclass function（對應的是多態性），所以導致了每個函數必須被包在一個對象里面（受約束的函數指針）才能傳遞到其它地方。 #### **勻稱的數據結構 + 勻稱的算法** ***** 程序 = 勻稱的數據結構 + 勻稱的算法 ***** 如圖所示  我們在編程中，不可能使用純的對象（對象的行為方法其實就是函數），或者純的函數（調用函數的對象、函數操作的數據其實就是數據結構）來創造一個完整的世界。如果 數據結構是陰 ， 算法是陽 ，那么在解決實際問題中，往往是陰陽交合而成世界。 真實的編程世界，自然是勻稱的數據結構結合勻稱的算法（SDS-SA）來創造的。 **函數與映射** 一切皆是映射。函數式編程的代碼主要就是“對映射的描述”。我們說組合是編程的本質，其實，組合就是建立映射關系。 一個函數無非就是從輸入到輸出的映射，寫成數學表達式就是： ``` f: X -> Y p:Y -> Z p(f) : X ->Z ``` 用編程語言表達就是： ~~~ fun f(x:X) : Y{} fun p(y:Y) : Z{} fun fp(f: (X)->Y, p: (Y)->Z) : Z { return {x -> p(f(x))} } ~~~