什么時候選擇功能編程而不是面向對象？

當您預計會有另一種軟件演變時：

當您對事物進行固定的操作時，面向對象的語言非常有用，并且隨著代碼的發展，您主要添加新的事物。這可以通過添加實現現有方法的新類來完成，而現有類則不理會。

當您擁有固定的事物集時，功能語言是很好的選擇 ，并且隨著代碼的發展，您主要在現有事物上添加新的操作。這可以通過添加使用現有數據類型進行計算的新函數來完成，而現有函數則不予考慮。

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

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

向功能程序中添加新事物可能需要編輯許多功能定義以添加新案例。

這個問題已經眾所周知很多年了。1998年，菲爾·沃德勒（Phil Wadler）將其稱為“表達問題”。盡管一些研究人員認為表達問題可以通過混合函數之類的語言功能解決，但尚未得到廣泛接受的解決方案成為主流。

函數編程是更好的選擇，典型的問題定義是什么？

功能語言擅長以樹形形式處理符號數據。最喜歡的例子就是編譯器，在源和中間語言改變很少（幾乎相同的事情），但是編譯器作者一直在增加新的翻譯和代碼改進或優化（對事物的新操作）。編譯和翻譯通常是功能語言的“殺手級應用”。

您不必在兩個范式之間進行選擇。您可以使用許多功能概念來編寫具有OO體系結構的軟件。FP和OOP本質上是正交的。

以C＃為例。您可以說這主要是面向對象的，但是有許多FP概念和構造。如果您考慮使用Linq，則允許Linq存在的最重要的構造實際上是功能性的：lambda表達式。

另一個示例F＃。您可以說它主要是FP，但是有許多OOP概念和構造可用。您可以定義類，抽象類，接口，處理繼承。當可變性使您的代碼更清晰或極大地提高性能時，您甚至可以使用可變性。

許多現代語言是多種范例。

推薦讀物

當我在同一條船上（OOP背景，學習FP）時，建議您閱讀一些我非常贊賞的讀物：

日常.NET開發的函數式編程，作者Jeremy Miller。一篇很棒的文章（盡管格式不佳）顯示了C＃上FP的許多技術和實際示例。

現實世界中的函數式編程，作者：Tomas Petricek。一本很棒的書，主要涉及FP概念，試圖解釋什么時候應該使用它們。F＃和C＃中都有很多示例。另外， Petricek的博客是一個很好的信息來源。

面向對象編程提供：

封裝，以

內部狀態控制突變

限制耦合到內部表示

子類型化，允許：

兼容類型的替換（多態）

在類之間共享實現的粗略方法（實現繼承）

在Haskell甚至在Scala中，函數式編程可以通過類型類的更通用機制進行替換。不鼓勵或禁止使用可變的內部狀態。內部表示的封裝也可以實現。參見Haskell與OOP進行比較。

諾曼的斷言“在功能程序中添加新事物可能需要編輯許多功能定義以添加新案例?！?取決于功能代碼使用類型類的程度。如果將特定抽象數據類型上的模式匹配分布在整個代碼庫中，則您確實會遭受此問題的困擾，但是從一開始它可能是一個較差的設計。

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