英文原文：Object-Oriented Programming Strikes Back!

免责声明：该帖子含有风趣成份，假如您对风趣类题材比较敏感，建议您中止浏览。

比来，我浏览了宣布在 DZone 上的关于面向工具编程的文章。我在博客上发明过好几篇关于面向工具编程的函数编程文章。一切这些帖子都在说，面向工具编程曾经灭亡（或多或少）。我以为一切这些帖子存在根本问题的曲解：没有真正了解甚么是函数编程。如今是时分让我谈谈分歧编程范式之间的争辩了。

起首，我想说，我尊敬上述文章作者的看法。我要说的是我个人对这个问题的见解。对这个富有争议的问题上没有绝对准确或绝对错误的观念。所以，请大师不要相互进犯。

函数式编程是甚么？

我以为为了更好天文解我对函数式编程的观念，起首必需了解函数式编程是甚么意思。

在盘算机范畴，函数式编程是一种编程范式 [..] ，它将盘算机运算视为数学上的函数盘算，而且防止形态变卦和数据可变。

这是维基百科给出的定义。你读过 lambda 表达式吗？没有。因而，在代码中滥用 lambda 表达式其实不意味着您运用的是函数式编程范型。

起首，您需求“援用通明性”，这意味着任什么时候候运用类似输出的挪用函数必需前往类似的输出。完成援用通明性的先决前提是形态的稳定性。一旦创立了一个构造（我们可以说一个类型？），就不克不及在随后以任何方法实行修正。

容易吗？援用通明性意味着没有反作用，没有异常抛出，没有从内部起源的读取等等。假如没有这些才能，我们怎么才干完成高产出呢？

故事的难点

我们仿佛被困在一个黑洞里，不是吗？我不克不及在一个函数内发生反作用（这其实不坏），我不克不及向函数挪用者收回旌旗灯号，说可能出了问题，我不克不及拜访任何内部资本。哦，天哪！

你传闻过幺半群、函子、票据吗？这些构造间接来自于范围论，数学的一个分支。描绘这些构造超越了本文的范畴，但我们可以举一些例子。

我断定地晓得你在你的代码中最少运用一些票据（Monad）。假如你是一个 Scala 开发者，极可能你运用过 Option[T] 类型，或 [T, E]，或任何一种聚集比方 List[T]、Set[T] 等。假如你是一个 Java 开发者，你可以把 Optional<T>、Collection<T> 和 Stream<T> 类型归入思索。一切这些类型都是票据（Monad）。

这些类型从行动的角度看没有任何配合的地方，这意味着票据（Monad）是一种机制，用于在相互不间接相干的类型之间同享一些属性（根本上，代码复用）。这是甚么意思？下文援用自 Scala 设计形式，

票据（Monad）构造代表盘算的步调序列。票据（Monad）被用于构建一切都不成变的管道，而洁净拖拉地给一门言语增加带有反作用的操作。

让我们从优良图书 Scala 函数式编程借用票据（Monad）的定义：

一个票据（Monad）是一元组合子的最小集（即 unit 和 flatMap）之一的完成，知足联合性和统一性的规律。

一元联合子？联合性？统一性？独角兽？Wtf?!!? 我只是一个通俗的开发职员：我传闻过数学，我改动编程范式。

我想用这篇论文来讲明甚么？真实的函数式编程实践上触及数学纪律和实际。假如你服从这些纪律开发你的顺序，就会从一组好的属性中获益，比方可组合性、可测性、线程限制，间接来自数学实际。

但是，你需求进修数学。范围论的细雨滴将会沾湿你的脸庞。

面向工具编程

面向工具编程是甚么呢？ 你是否碰到过你必需遵照的无聊的数学规律？ 你是否听过有关诸如 monad 或 functor 如许的深邃辞汇，仍是此外甚么？ 你是否将一些数学实际使用于面向工具的顺序中？

没有。面向工具编程的漂亮的地方在于它是与数学有关的。每一个人都可以进修面向工具的编程言语，如 Java、C ++ 或 Kotlin。第一印象里，面向工具的编程十分靠近于我们看待现实天下的办法。

其它翻译版本 (1) 加载中

作为生涯活着界侥幸地域的人类，我们晓得车都是由发起机、一些轮子、一个车身等组成的。我们清楚 Car 类型是甚么意思，为何它具有引擎、车轮和车身的属性。

面向工具编程比函数式编程更轻易进修。 到此为止。这是独一的现实。 从盘算机时期Start，这两种形式就或多或少地存在（例如，想一想在 1958 年创造的 Lisp）。你是否传闻过用函数式编程言语来编写的操作系统的？ 没有。

容易化招致的衡量

更容易意味着更少的束缚。  更少的束缚意味着更少的拘泥于方式。更少的方式意味着更轻易用一种错误的方法运用编程言语的特征。

以我们方才提出的一元定义为例。 在定义中，类型必需知足的束缚长短常明白的指定为一元。 数学不会扯谎。

如今，采取面向工具编程的任何准绳：例如，单一义务准绳。 准绳规则：

一个类只因一个来由而改动。

需求改动的缘由终究是甚么？一切实用于函数编程言语的数学邪术在那里？没有。

在与面向工具编程有关的一切实际的根底上，耦合的定义都不是以正式的方法定义的。

组件之间的耦合取决于其依靠水平。

好吧，那末怎么权衡组件之间的依靠水平？ 没有正式的方法。 我试图在我过来的帖子“依靠关系”中给出耦合的数学定义，但这只是一个实验。

缺少严谨的道理定义招致了道理的解读。个人的解读常常招致错误和不良做法。

本文中的一切译文仅用于进修和交换目标，转载请务必注明文章译者、出处、和本文链接。 2KB翻译任务按照 CC 协议，假如我们的任务有进犯到您的权益，请实时联络我们。

2KB项目（www.2kb.com，源码交易平台）,提供担保交易、源码交易、虚拟商品、在家创业、在线创业、任务交易、网站设计、软件设计、网络兼职、站长交易、域名交易、链接买卖、网站交易、广告买卖、站长培训、建站美工等服务