函數式編程與面向對象編程[關閉]

到目前爲止，我已經主要接觸過OO編程，並期待學習一門函數式語言。 個人問題是：

• 何時選擇面向對象的函數式編程？
• 什麼是典型的問題定義，其中函數式編程是更好的選擇？

---

#1樓

您不必定要在兩種範例之間進行選擇。 您可使用許多功能概念編寫具備OO架構的軟件。 FP和OOP本質上是正交的 。

以C＃爲例。 你能夠說它主要是OOP，但有許多FP概念和結構。 若是考慮Linq ，容許Linq存在的最重要的構造本質上是功能性的： lambda表達式 。

另外一個例子，F＃。 你能夠說它主要是FP，但有許多OOP概念和結構可用。 您能夠定義類，抽象類，接口，處理繼承。 您甚至能夠在使代碼更清晰或顯着提升性能時使用可變性。

許多現代語言都是多範式的。

推薦讀物

由於我在同一條船上（OOP背景，學習FP），我建議你讀一些我真的很感激：

• Jeremy Miller 爲平常.NET開發提供的功能編程 。 一篇很棒的文章（雖然格式不好），展現了C＃上FP的許多技術和實際的實際例子。

• 真實世界的功能編程 ，由Tomas Petricek撰寫。 一本偉大的書，主要涉及FP概念，試圖解釋它們是什麼，何時應該使用它們。 F＃和C＃都有不少例子。 此外， Petricek的博客是一個很好的信息來源。

---

#2樓

1. 若是您處於高度併發的環境中，那麼純函數式編程就頗有用。 缺少可變狀態使得併發幾乎是微不足道的。 見Erlang。

2. 在多範式語言中，若是可變狀態的存在必須是實現細節，您可能但願在功能上對某些事物進行建模，所以FP是問題域的良好模型。 例如，請參閱D編程語言中的Python或std.range中的列表推導 。 這些都受到函數式編程的啓發。

---

#3樓

何時選擇面向對象的函數式編程？

當您預期不一樣類型的軟件演變時：

• 當你對事物有一套固定的操做時，面向對象的語言是很好的，隨着代碼的發展，你主要添加新東西。 這能夠經過添加實現現有方法的新類來完成，而且現有類保持不變。

• 當你有一套固定的東西時 ，函數式語言是很好的，隨着代碼的發展，你主要在現有的東西上添加新的操做 。 這能夠經過添加使用現有數據類型計算的新函數來實現，而且現有函數是獨立的。

當進化走錯路時，你會遇到問題：

• 向面向對象的程序添加新操做可能須要編輯許多類定義以添加新方法。

• 在功能程序中添加新類型的東西可能須要編輯許多函數定義來添加新案例。

這個問題多年來一直衆所周知; 1998年， Phil Wadler將其稱爲「表達問題」 。 雖然一些研究人員認爲表達問題能夠經過mixins這樣的語言特性來解決，可是一種被普遍接受的解決方案還沒有成爲主流。

什麼是典型的問題定義，其中函數式編程是更好的選擇？

功能語言擅長以樹形式操縱符號數據。 最喜歡的例子就是編譯器，在源和中間語言改變不多（幾乎相同的事情 ），可是編譯器做者一直在增長新的翻譯和代碼改進或優化（對事物的新操做）。 編譯和翻譯更通常地是功能語言的「殺手級應用」。

---

#4樓

面向對象編程提供：

1. 封裝，到
   • 控制內部狀態的突變
   • 限制耦合到內部表示
2. 子類型，容許：
   • 替換兼容類型（多態）
   • 在類之間共享實現的粗略方法（實現繼承）

Haskell甚至Scala中的函數式編程能夠容許經過類型類的更通用機制進行替換。 不鼓勵或禁止可變的內部狀態。 還能夠實現內部表示的封裝。 有關比較，請參閱Haskell與OOP 。

Norman斷言「在功能程序中添加新東西可能須要編輯許多函數定義來添加新案例」。 取決於功能代碼使用類型類的程度。 若是特定抽象數據類型上的模式匹配遍及整個代碼庫，您確實會遇到這個問題，但它多是一個糟糕的設計。

EDITED在討論類型類時刪除了對隱式轉換的引用。 在Scala中，類型類使用隱式參數進行編碼，而不是轉換，儘管隱式轉換是實現兼容類型替換的另外一種方法。