函数式编程支持者将如何在Code Complete中回答此声明？

在第二版的839页上，史蒂夫·麦康奈尔（Steve McConnell）讨论了程序员在大型程序中“克服复杂性”的所有方式。他的提示最终体现在：

“面向对象的编程提供了同时适用于算法和数据的抽象级别，这是仅功能分解无法提供的那种抽象。”

加上他的结论“降低复杂度可以说是成为有效程序员的最重要的关键”（同一页），这似乎对函数式编程构成了很大的挑战。

FP和OO之间的辩论通常由FP支持者围绕复杂性问题进行，这些复杂性问题特别来自于并发或并行化的挑战。但是并发当然不是程序员必须克服的唯一复杂性。也许专注于减少一种复杂性会在其他方面大大增加它的复杂度，以至于在许多情况下，增加收益是不值得的。

如果我们将FP和OO之间的比较术语从并发性或可重用性等特定问题转移到全局复杂性的管理上，那场辩论会如何？

编辑

我想强调的对比是，OO似乎封装和抽象了数据和算法的复杂性，而函数式编程似乎鼓励在整个程序中使数据结构的实现细节更加“暴露”。

例如，参见Stuart Halloway（Clojure FP的支持者）在这里说，“数据类型的过度规范”是“惯用的OO风格的负面结果”，并主张将AddressBook概念化为简单的矢量或映射而不是更丰富的OO对象。以及其他（非向量化和非地图类）属性和方法。（此外，OO和领域驱动设计的支持者可能会说，将地址簿公开为向量或映射会使封装的数据过度暴露于从域的角度来看无关紧要甚至危险的方法）。

请记住，这本书写了20多年了。对于当今的专业程序员而言，FP不存在-它完全在学者和研究人员的范围内。

我们需要在工作的适当范围内构架“功能分解”。作者不是指功能编程。我们需要将其绑定到“结构化编程”以及GOTO它之前的混乱局面。如果您的参考点是没有功能的旧版FORTRAN / COBOL / BASIC（也许，如果您很幸运，您将获得一个单一的GOSUB级别），并且所有变量都是全局变量，则可以分解程序分成几层功能是一大福音。

OOP是对这种“功能分解”的进一步改进。您不仅可以将指令捆绑在功能中，还可以将相关功能与它们正在处理的数据进行分组。结果是一段清晰定义的代码，您可以查看（理解）（理想情况下），而不必全神贯注于代码库中以查找其他可能对数据起作用的代码。

我想象函数式编程的支持者会争辩说，大多数FP语言比“单独的函数分解”提供了更多的抽象方法，并且实际上确实允许抽象方法在功能上与面向对象语言相提并论。例如，可以引用Haskell的类型类或ML的高阶模块作为这种抽象方法。因此，该声明（我很确定是关于面向对象而不是过程编程，而不是函数式编程）不适用于它们。

还应该指出的是，FP和OOP是正交的概念，并不相互排斥。因此，将它们相互比较是没有意义的。您可以很好地将“命令式OOP”（例如Java）与“功能性OOP”（例如Scala）进行比较，但是您引用的语句不适用于该比较。

我发现函数式编程在管理复杂性方面非常有帮助。但是，您倾向于以不同的方式来考虑复杂性，将其定义为对不同级别的不可变数据起作用的函数，而不是从OOP的角度进行封装。

例如，我最近用Clojure编写了一个游戏，并且游戏的整个状态都在一个不变的数据结构中定义：

(def starting-game-state {:map ....
                          :player ....
                          :weather ....
                          :other-stuff ....}

游戏的主循环可以定义为在循环中将一些纯函数应用于游戏状态：

 (loop [initial-state starting-game-state]
   (let [user-input (get-user-input)
         game-state (update-game initial-state user-input)]
     (draw-screen game-state)
     (if-not (game-ended? game-state) (recur game-state))))

称为的关键函数是update-game，该函数在给定先前的游戏状态和某些用户输入的情况下运行模拟步骤，并返回新的游戏状态。

那么复杂性在哪里呢？在我看来，它已经得到很好的管理：

• 当然，更新游戏功能可以完成很多工作，但是它本身是由其他功能组成的，因此它实际上非常简单。一旦下降了几级，功能仍然非常简单，可以执行“将对象添加到地图图块”之类的操作。
• 当然，游戏状态是一个大数据结构。但同样，它只是通过构成较低级别的数据结构而建立的。同样，它是“纯数据”，而不是嵌入任何方法或需要类定义（如果愿意，您可以将其视为非常有效的不可变JSON对象），因此几乎没有样板。

OOP还可以通过封装来管理复杂性，但是如果将其与OOP进行比较，则该功能具有一些非常大的优点：

• 游戏状态数据结构是不可变的，因此可以轻松地并行执行许多处理。例如，在与游戏逻辑不同的线程中进行渲染调用绘图屏幕是绝对安全的-它们可能不会相互影响或看到不一致的状态。对于大型可变对象图，这是令人惊讶的困难……
• 您可以随时拍摄游戏状态的快照。重播是微不足道的（感谢Clojure的持久数据结构，由于大多数数据是共享的，因此副本几乎不占用任何内存）。例如，您还可以运行更新游戏来“预测未来”，以帮助AI评估不同的动作。
• 我无需在任何地方进行任何艰难的权衡以适应OOP范式，例如定义严格的类继承关系。从这个意义上说，功能数据结构的行为更像是一个基于原型的灵活系统。

最后，对于那些对如何管理功能性语言和OOP语言的复杂性有更多见解的人，我强烈推荐Rich Hickey的主题演讲Simple Made Easy的视频（在Strange Loop技术会议上拍摄）

“面向对象的程序设计提供了同时适用于算法和数据的抽象层次，这是仅功能分解无法提供的一种抽象。”

仅仅功能分解还不足以构成任何类型的算法或程序：您还需要表示数据。我认为上面的陈述隐含地假定（或至少可以这样理解）功能情况下的“数据”是最基本的类型：仅是符号列表，而没有其他内容。用这种语言编程显然不是很方便。但是，许多语言，尤其是新近现代的功能（或多范式）语言（例如Clojure）提供了丰富的数据结构：不仅是列表，而且还包括字符串，向量，映射和集合，记录，结构以及对象！-具有元数据和多态性。

OO抽象的巨大实际成功是无可争议的。但这是硬道理吗？如您所写，并发问题已经是主要的难题，而经典的OO根本不包含并发的概念。结果，用于处理并发的事实上的OO解决方案只是叠加了胶带：可以工作，但是很容易搞砸，需要大量的脑部资源来处理当前的基本任务，而且伸缩性不好。也许有可能充分利用世界上最好的东西。这就是现代多范式语言所追求的。

可变状态是与编程和软件/系统设计有关的大多数复杂性和问题的根源。

OO包含可变状态。FP讨厌可变状态。

OO和FP都有其用途和优点。做出明智的选择。记住这句格言：“封闭是穷人的物件。物件是穷人的封闭物。”

函数式编程可以具有对象，但是那些对象往往是不可变的。然后，纯函数（没有副作用的函数）将在这些数据结构上运行。可以使用面向对象的编程语言来制作不可变的对象，但是它们并不是为了做到这一点而设计的，这并不是它们倾向于被使用的方式。这使得很难对面向对象的程序进行推理。

让我们举一个非常简单的例子。假设Oracle决定Java Strings应该具有反向方法，并且您编写了以下代码。

String x = "abc";
StringBuffer y = new StringBuffer(x);
y.reverse();
x.reverse();
x.toString().equals(y.toString());

最后一行的计算结果是什么？您需要有关String类的特殊知识，才能知道这将得出false。

如果我自己上课WuHoString怎么办

String x = "abc";
WuHoString y = new WuHoString(x);
y.reverse();
x.reverse();
x.toString().equals(y.toString())

不可能知道最后一行的计算结果。

在函数式编程风格中，它的编写方式如下：

String x;
equals(toString(reverse(x)), toString(reverse(WuHoString(x))))

这应该是真的。

如果最基本的类之一中的1个函数很难如此推理，那么一个人想知道引入这种可变对象的想法是否会增加或减少复杂性。

显然，对于面向对象的构成，功能的含义以及两者的含义都有各种各样的定义。对我来说，您可以使用没有一流函数之类的语言的“函数式编程风格”，但可以使用其他语言。

我认为在大多数情况下，经典的OOP抽象无法涵盖并发复杂性。因此，OOP（按其原始含义）并不排除FP，这就是为什么我们会看到scala之类的原因。

答案取决于语言。例如，Lips确实非常清楚代码是数据，而您编写的算法实际上只是Lisp列表！您以与编写程序相同的方式存储数据。同时，这种抽象比OOP更简单，更透彻，可让您做一些真正整洁的事情（检出宏）。

Haskell（我想和类似的语言）有一个完全不同的答案：代数数据类型。代数数据类型就像C结构，但有更多选择。这些数据类型提供了对数据建模所需的抽象。函数提供对算法建模所需的抽象。类型类和其他高级功能提供了更高的抽象级别。

例如，我正在尝试一种名为TPL的编程语言。代数数据类型使表示值非常容易：

data TPLValue = Null
              | Number Integer
              | String String
              | List [TPLValue]
              | Function [TPLValue] TPLValue
              -- There's more in the real code...

以一种非常直观的方式，这就是说TPLValue（我的语言中的任何值）可以是一个Null或一个Number具有Integer值的a 或a ，甚至可以是具有值Function列表（参数）和最终值（主体）的a ）。

接下来，我可以使用类型类对一些常见行为进行编码。例如，我可以创建TPLValue实例，Show这意味着可以将其转换为字符串。

另外，当我需要指定某些类型的行为（包括我自己未实现的行为）时，可以使用自己的类型类。例如，我有一个Extractable类型类，可让我编写一个函数，该函数采用a TPLValue并返回适当的普通值。因此，只要和是的实例，extract就可以将a转换Number为an Integer或a 转换String为a 。StringIntegerStringExtractable

最后，我程序的主要逻辑在于几个函数，例如eval和apply。这些实际上是核心-它们取TPLValues并将其转换为more TPLValue，以及处理状态和错误。

总的来说，我在Haskell代码中使用的抽象实际上比我在OOP语言中使用的抽象更强大。

据我所知，引用的句子已不再有效。

当代的OO语言不能抽象类型不是*的类型，即更高种类的类型是未知的。它们的类型系统不允许表达“带有Int元素的容器，该容器允许在元素上映射函数”。

因此，像Haskells这样的基本功能

fmap :: Functor f => (a -> b) -> f a -> f b 

例如，至少不能以类型安全的方式编写）。因此，要获得基本功能，您必须编写大量样板，因为您需要

1. 一种将简单函数应用于列表元素的方法
2. 一种将相同简单函数应用于数组元素的方法
3. 一种将相同的简单函数应用于哈希值的方法，
4. ....集
5. ....树
6. ... 10.相同的单元测试

但是，这五个方法基本上是相同的代码，可以使用或可以使用某些方法。相反，在Haskell中，我需要：

1. 列表，数组，映射，集合和树的Functor实例（通常是预定义的，或者可以由编译器自动派生）
2. 简单功能

请注意，Java 8并不会改变这种情况（只是可以更轻松地应用函数，但是，恰恰会出现上述问题。只要您没有更高阶的函数，您很可能甚至不会能够了解更高种类的类型的优点。）

即使像锡兰这样的新OO语言也没有更高种类的类型。（我最近问过加文·金，他告诉我，这在当时并不重要。）不过，我不了解科特林。

*）公平地说，您可以拥有一个接口Functor，该接口具有方法fmap。不好的事情是，您不能说：嘿，我知道如何为库类SuperConcurrentBlockedDoublyLinkedDequeHasMap，亲爱的编译器实现fmap，请接受从现在开始，所有SuperConcurrentBlockedDoublyLinkedDequeHasMaps都是Functors。

曾经在dBase中进行过编程的任何人都会知道单行宏对于制作可重用的代码有多么有用。尽管我还没有用Lisp编程，但是我从许多宣读编译时间宏的人那里读到了很多东西。在每个C程序中使用“ include”指令以一种简单的形式使用在编译时将代码注入代码的想法。由于Lisp可以使用Lisp程序执行此操作，并且由于Lisp具有高度的反射性，因此您可以获得更加灵活的包含。

只会从网络上获取任意文本字符串并将其传递到其数据库的任何程序员都不是程序员。同样，任何允许“用户”数据自动成为可执行代码的人都是愚蠢的。这并不意味着允许程序在执行时操纵数据，然后将其作为代码执行是一个坏主意。我相信，这种技术在将来必不可少，因为它将实际上编写大多数程序的“智能”代码。整个“数据/代码问题”与否取决于语言的安全性。

大多数语言的问题之一是它们是由一个离线人员自己执行的。现实世界中的程序要求许多人始终可以同时访问多个Core和多个计算机集群。安全性应该是语言的一部分，而不是操作系统的一部分，并且在不久的将来它将成为安全性。