我们正在用更糟糕的东西取代面向对象编程（OOP）

面向对象编程（OOP）正在在不同领域之间转移，而不是消失。我认为这通常是一件坏事。

---

人们已经对面向对象编程（OOP）话题进行了大量的讨论：什么是OOP？为什么需要OOP？OOP是否好？我不确定我有答案，但我观察到一个有趣的趋势，我认为它已经飞过了雷达：OOP并没有消失，而是正在在不同领域之间转移。

简要而完全不正确的历史

在过去，人们编写程序。事情很简单。然后，一位不知道自己会带来多少麻烦的经理让两位程序员合作开发同一个程序。糟糕的事情发生了。

一位聪明的程序员意识到，错误经常出现在软件功能的交叉点，并且执行一些侵入性手术来分离这些功能可能是一个好主意，使用一个接口：一个至少有一定明确的合同，描述两个函数之间的行为。

其他聪明的程序员加入了讨论：如果这种分离不依赖于程序员的个人卫生（这应该始终被质疑，出于公共卫生原因），而是由语言强制执行呢？组件可能会默认隐藏其实现，并且只通过一组公共函数进行通信，语言可能会拒绝试图绕过这些屏障的程序。多么可爱。

如今，我们有许多术语来描述这些概念，以及其他后续概念，试图进一步传播核心思想：封装、继承、多态性。所有这些都旨在通过强制减少组件之间传递的信息。当然，这个核心思想并非OOP所独有，但OOP是其拥护者，并以热情投入战斗。

程序作为类

大约在同一时间，一位聪明的程序员意识到，程序员（一个以个人卫生不佳著称的群体）可能不会产生最干净的程序，并且可能不应该信任所有在计算机上运行的小程序。因此，进程边界诞生了，操作系统从友好的个人助手转变为保姆，其主要工作是确保其照顾的程序不会意外地互相喂食蜗牛或回形针。

同时，其他聪明的程序员发现，计算机可以相互通信，这可能是有用的。现在，来自不同开发人员（甚至可能彼此不认识或不信任）的程序可以开始相互交互。

当信任崩溃时，社会往往会过度热情地建立最高和最厚的墙，无论代价如何。软件开发人员也不例外。当每个程序都演变成一个由大量开发人员创建的组件风暴，而这些开发人员很少知道其软件的包含，甚至更少地讨论它时，那么唯一合理的反应就是最大程度的不信任。

因此，进程/网络边界自然成为最高和最厚的墙——正好在面向对象编程的哲学变得过时之时取代了它。

这值得吗？

我们今天的世界是一个微服务、Docker、集群和“扩展”的世界。最大的讽刺是，尽管人们在谈论Java时会对OOP表示怀疑，但我们用一个具有相同缺陷（但放大了十倍）的庞然大物取代了它。OpenAPI模式取代了类型检查器，Docker Compose取代了服务工厂，Kubernetes取代了事件循环。组件之间的每个调用都会产生故障模式，需要通过（反）序列化库进行缓慢的行进，需要通过内核调度器进行长时间的跋涉。这里可能会有TLB缓存失效，那里可能会有套接字轮询。也许还会有一个偷偷的HTTP请求到localhost进行“甜点”。

我并不被OOP的承诺说服，但我更不相信取代它的东西的花言巧语。