是时候摆脱OOP了
OOP被认为是计算机科学领域中最大的钻石。组织代码的最佳方法。解决所有问题。编写程序的唯一可靠方法。编程之神从上面把我们引向了我们……只有在这里，OOP程序员才被迫抽出各种抽象，监视所有共享对象，记住大量的“编程模式”，并花时间和精力在所有这些上，而不是自己解决问题。
长期以来，许多人都对OOP提出了批评，而这些批评家中也有许多受人尊敬的程序员。甚至OOP的发明者艾伦·凯（Alan Kay）也在他们的行列中！
任何开发人员的主要目标是编写可靠的代码。如果代码有错误，并且无法按预期工作，那么其他任何事情都不重要。编写可靠代码的最佳方法是什么？保持代码简单。简单是复杂的相反。因此，开发人员的主要目标是降低代码的复杂性。
免责声明：
我不是OOP爱好者，因此这篇文章似乎对许多人有偏见也就不足为奇了。但是，我将提出辩护以捍卫自己的立场。
我也非常了解，对OOP的批评对于许多人来说是非常痛苦的。如此众多的读者会觉得自己很生气。但是，我打算陈述我认为正确的内容。我的目标不是冒犯，而是指出OOP存在的问题。我并不是在批评Alan Kay
的OOP。他通常是个天才。就个人而言，我希望OOP完全符合Alan Kay的意图。我批评的是C＃或Java实现中的OOP。
问题是OOP长期以来一直被视为组织代码的标准。许多人认为，包括那些在软件行业中担任重要职务的人，这就是为什么大多数公司甚至不考虑其他编程方法的原因。
用OOP语言编写时，我必须克服很多困难。我一直想知道为什么会出现这些困难。也许我不太好？也许我需要学习更多的“编程模式”？最后，我只是没有足够的力量来完成所有这些工作。
本文将告诉您我从OOP到函数式编程的十年旅程。从那时起，我不记得有一个案例，我遇到过一个最适合OOP的项目。而且，使用OOP的项目在代码复杂性的压力下失败了–从某个角度来看，不可能进一步维护和开发它们。
TLDR
“面向对象的程序是正确程序的替代方案。”
Edsger W. Dijkstra，计算机科学先驱
OOP的目标是一个-处理程序代码的复杂性。换句话说，OOP旨在改善代码组织。但是从那以后，没有证据表明OOP比旧的过程编程要好。
严酷的事实是，OOP并没有完成它原本打算做的一件事。一切在纸上看起来都很好-我们具有严格的动物，狗，人的层次结构...（当然，形状：矩形，正方形和圆形-我们可以在没有它们的情况下走到哪里！）但是随着应用程序代码的复杂性增加，OOP并没有帮助减少它但是，相反却增加了-伴随着大量必要的``编程模式''，这使得程序员难以跟踪变量的值在何处以及如何变化。 OOP使许多常用的过程（例如重构和测试）变得不必要地复杂。
许多人不同意我的看法，但事实是，用科学方法没有考虑过用C＃或Java进行OOP的设计，这不是认真科学研究的结果。与函数编程不同，例如在Haskell中，lambda演算是坚实的理论基础。 OOP不是基于这样的东西。
在小型项目中，OOP表现良好。但是当项目发展时会发生什么呢？ OOP是定时炸弹，当项目代码达到一定大小时，它将不可避免地爆炸。项目开始滞后，截止日期失败，开发人员用尽了精力，添加新功能几乎变得不可能。最后，公司被迫将此类代码标记为“过时”，并迫使开发人员进行重写。
OOP与我们的大脑思维方式不太吻合。我们习惯于专注于行动：散步，与朋友交谈，吃披萨。我们的大脑已经朝着“做某事”发展，而不是朝着建立复杂的抽象对象层次结构发展。
OOP代码是不确定的（与函数编程不同）：我们不能确定使用相同的输入数据每次都会得到相同的结果。这使得很难理解程序的工作方式。这是一个简单的示例：比较2 + 2和Calculator.Add（2，2）。理论上，最后一个表达式应始终返回4，但可以返回5、3甚至1004，因为Calculator对象的依赖性 可以以最不可预测的方式改变他的行为。