该帖子包含一定程度的取笑，卫生部令人信服地要求未准备好的读者不要阅读。关于“ AF更好”或“ OOP更好”主题的文章类似于关于什么是午餐，叉子或汤匙的最佳讨论。 传统上，六月是从汤匙开始的，但是一个非常有权威的人曾经告诉我说他只吃肉并且用叉子，所以诞生了一种新的时尚-吃叉子。 他们吃稀饭和汤，甚至设法吃冰沙。 互联网上到处都是文章，我们多么出色，我们学会了用叉子吃冰沙，克服了所有困难。 这既可笑又可悲，一方面，它给经验丰富的家伙提供了竞争优势，这些家伙仅仅忽略这种炒作就表现出了出色的成绩;另一方面，他们不得不对同事和员工进行再培训，清理头顶上的风所造成的垃圾。 在本文中，我将尝试说出我的愿景，虽然它并不声称是绝对真理，但在实践中效果很好
按照科学惯例，我们从定义开始。 OOP的经典定义涉及遵循继承，封装和多态性的原理。 但是，如果我们没有这些组件之一，它将是OOP吗？ 如果没有，那会是什么？
尽管无聊的听众徘徊在这个不切实际的地方并且没有给我们任何问题，但 让我们回顾一下在巴解组织之前发生的事情 。 在他之前是过程编程。 当时OOP的主要思想是将
数据和函数进行处理的
连接 。 这个想法很简单，但具有革命性，很难想象有多少，但以后会更多。
在自由解释的情况下，函数式编程将
程序视为数学公式 。 公式已形式化，并且具有相同的输入将返回相同的输出。 整个程序由遵循相同原理的例程组成。 这与同一过程编程有何不同？ FP积极使用
纯函数 ；理想情况下，整个程序应为纯函数。 纯函数
没有副作用 ，可以轻松地对其进行记忆，测试等。。。可以说，纯函数的主要思想和优点是FP。
现在有两个问题：
-我们可以在OOP中使用纯函数吗？
-我们可以将功能绑定到FP中的数据吗？
他们两个的答案都是肯定的。 静态类方法可以是纯净的，即使实例方法不产生副作用，并且我们将类实例的属性视为参数，也可以认为它们是干净的。 古典定义的边界被夸大，有些可能会不同意，但实际上它是可行的。 并且对这些方法进行了形式化和测试，并不比根据所有规范编写的经典纯函数更糟糕。 关于将数据绑定到数据的方法稍微复杂一些，所使用的语言和库施加了限制。 假设在JavaScript中这是基本完成的操作，不确定Haskell和Erlang。 现在最有趣的是它所提供的东西，以及为什么OOP在20到30年前就已经进行了如此大肆宣传。 如果您编写的是小型程序，则可以随意编写，除了您的美感外，它不会影响任何内容。 当您创建一个很大的程序时，就会出现复杂性问题。 不是计算复杂，我们相信这里做得很好，但是感觉到复杂。 假设您有50,000行代码，它们都非常有用。 如何组织他们以免发疯（或不让他们晚上11个工作离开）？ 我们不能减少操作的数量，但是可以减少它们之间的连接的数量（封装可以帮助我们实现这一点）。 我们将复杂的实现隐藏在一个简单的界面后面，并且仅继续使用该界面。 例如，互联网是一件非常复杂的事情，但是大多数开发人员都对HTTP协议有足够的了解，可以完成他们的工作
，并将网络，物理和其他级别留给系统管理员 。 我们的模块之间的连通性
越弱，它们彼此集成阶段的
复杂性就越低 。 一个模块对另一模块的了解越少，它们之间的连接就越少。 将方法绑定到模块内部的数据有助于我们摆脱模块使用者的这些知识。 这是OOP的主要实用优势。 什么呢 上面的方法没有数据和方法的绑定。 我们发现，FP没有对此发表任何评论。 您可以将类作为纯函数的参数传递，也可以将纯函数用作类的方法，它并不相互矛盾，而只是对其进行补充。
实际上，一种方法主要在哪里起作用，另一种主要在哪里起作用？ 当我在NodeJS上编写
后端时，它本身就以某种
功能范例出现了。 怎么了 因为对服务器的请求本质上是一个功能，具有固定的输入和输出。 功能性方法非常自然地满足服务器的要求，并且代码更加紧凑和灵活。 当我为浏览器创建
前端时 ，
OOP通常会更好地工作，因为除了输入和输出之外，我们还具有
用户事件流以及程序事件流，例如动画的开始和结束，服务器请求等。如果只是绘制没有交互性的静态页面，则在前端使用FP时，交互或开发时间都会受到影响（根据我们的测量，每3次）。 怎么了
任何编程范例都基于某个现实模型，并且模型始终是简化模型。 在FP中，该模型对世界施加了更多限制，因此更易于形式化。 出于同样的原因，当它变得与问题的状况无关时，它开始需要更多的拐杖。 例如，前端FI通过创建事件（动作，redux hi）数组来解决用户输入问题。 但是，这是不相关的抽象，除了对其性能有影响外，还大大增加了开发时间。 通过这种方法，您可以创建待办事项清单，但是在非常大的项目中，您必须用额头砸砖块，然后为同样不幸的人写胜利的文章。 为了进行比较，当我们使用canvas，svg编写交换终端（当然是在vanilla js上）并通过websocket每秒更新几次时，在一些频繁更新的组件中，我们没有删除div，而是重复使用了它们，因为重新创建它们是相对昂贵的浏览器中的操作（如果您的
应用程序非常大 ，这一点很重要）。 如果您在前端进行编程，您甚至根本不会有这样的想法，因为您已经习惯了不变性（顺便说一句，这对于处理多线程来说是一件很了不起的事情，这在JS中
是不会发生的），因此每个动作都会经过每个reducer和其他垃圾。 另一方面，在后端，它通常根本不需要类，因为任务的条件与FP模型非常相关，因此在那里，您就可以避免创建它们的开销。 但是，在大多数情况下，Java和PHP开发人员并不急于研究FP，前端供应商处于最前列，而他们实际上是最不需要的。 作为一种锻炼头脑的方法-当然，这很有趣，只有获得这些程序，但是其他人可以使用它们。 尽管前端是IT的一个相对较年轻的部分，但它的未解决任务已有几代人了。 看来，这不是锻炼头脑吗？