面向对象编程中 35 年的错误：软件架构与历史背景的深度剖析

Better Software Conference

“错误”介绍 [00:00:00]

演讲者介绍了软件架构中一个重要的“35 年的错误”，特别是在面向对象编程（OOP）中。

• Looking Glass [1998] 和实体组件系统 (ECS) [00:00:50]

  • Looking Glass 是一家有影响力的游戏公司，于 1998 年开发了“神偷：黑暗计划”。

    

  • 按照今天的标准来看，这款游戏看起来很原始，但在当时是最先进的。

    

  • 与使用“胖结构体”（实体的单个大型结构体）或分层 OOP 模型（如 entity -> npc -> mech）的传统游戏开发实践不同，Looking Glass 开创了一种不同的方法。
  • 他们的创新是实体组件系统（ECS），其中实体只是 ID，数据（例如，物理、战斗、燃料）由单独的系统存储和管理，实体在这些系统中查找其数据。

    

  • ECS 中的封装边界围绕系统绘制，从而促进了面向数据的设计，这与传统的 OOP 不同，在传统的 OOP 中，边界围绕对象绘制。

    

• 核心问题：编译时层次结构匹配领域模型 [00:05:47]

  • Looking Glass 系统的主要实现者 Marc LeBlanc 确定了流行的 OOP 思维模式：“匹配领域模型的编译时层次结构”。
  • 这意味着软件结构被设计为直接反映现实世界的分类（例如，“守卫”子类化“NPC”），即使它对于代码来说不是最佳的。
  • 演讲者认为，这种方法虽然看似直观，但却错误地放置了封装边界，使得代码更难编写和维护。
  • 这个“错误”被明确定义为“匹配领域模型的封装的编译时层次结构是一个错误”。

    

“错误”的起源：C++ 和 Simula [00:16:32]

探讨了这个有问题的 OOP 范例的历史根源，从 C++ 及其前身 Simula 开始。

• Bjarne Stroustrup 和带类的 C [00:16:51]
  • C++ 的创建者 Bjarne Stroustrup 于 1978 年在剑桥大学开始了他在分布式系统仿真方面的工作，以获得博士学位。
  • 他学习了 Simula，一种仿真语言，并发现它的类概念对于将应用程序概念（例如，不同的计算机类型）直接映射到语言结构中非常有效。
  • Simula 提供了强大的类型检查，与当时较弱的类型系统（如 Pascal）相比，这是一个显着的优势。

    

  • 然而，Simula 的实现面临严重的性能问题，特别是糟糕的链接时间和垃圾收集器消耗了超过 80% 的运行时间，即使没有产生任何垃圾。
  • 这导致 Stroustrup 放弃了 Simula 作为他的主要工作，并用 BCPL 重写了他的模拟器，BCPL 是一种类型检查最少的语言。
  • 搬到贝尔实验室后，Stroustrup 试图将 C 的效率与 Simula 的有益特性结合起来，从而产生了“带类的 C”（后来的 C++）。他的目标是模块化和并发分析，利用类来实现受硬件启发的保护机制（例如，虚拟内存保护导致 private 访问说明符，操作系统读/写权限导致 const）。
  • 最初，带类的 C 没有虚函数，但后来从 Simula 添加了它们，优先考虑效率。
  • Stroustrup 最初还使用继承来实现代码重用（例如，链表的 link 类），但后来提倡使用模板来实现此目的，承认继承对于通用容器类来说并不理想。

追溯到 Simula 及其起源 [00:31:47]

为了理解核心思想，将血统进一步追溯到 Simula 的发展。

• 挪威计算中心 [1962]：Kristen Nygaard 和 Ole-Johan Dahl [00:32:14]
  • Kristen Nygaard 和 Ole-Johan Dahl 开发了 Simula。

    

  • 初始版本 Simula I [1963] 被设计为“系统仿真的脚本语言”，用于运营研究以模拟排队系统（例如，机场起飞）。
  • 该语言允许直接描述系统组件及其流程，从而生成用于优化的统计数据。
  • Simula I 取得了成功，从而开发了 Simula 67 以解决缺点并实现更大的可重用性。
  • Simula 67 的类概念的主要动机是代码重用，例如“桥上的收费站”场景（汽车、卡车、公共汽车）。他们想要定义一个通用的 car 类，truck 和 bus 可以从中继承，以及一个 link 类来启用链表功能。
  • 这表明领域建模和代码重用（通过继承）从 Simula 类概念的一开始就交织在一起。
  • Simula 还引入了动态分派机制，类似于虚函数，以处理基于对象类型的操作。

更深层次的根源：C.A.R. Hoare 和区分联合体 [00:41:59]

“子类”思想的起源归功于 C.A.R. Hoare，揭示了一个关键的分歧。

• C.A.R. Hoare [1966] 和“记录处理” [00:42:32]
  • Nygaard 和 Dahl 明确地将“子类思想”归功于 C.A.R. Hoare，特别是来自他对“记录类结构”的研究。
  • Hoare 的论文探讨了用互斥子类（例如，作为常量、变量、二元表达式的代数表达式）建模现实世界对象。

    

  • 至关重要的是，Hoare 的提案包括区分联合体（或标记联合体），其中记录具有类型字段和一个 consider when ... then 结构，用于类型安全的条件分支和访问特定的子类型字段。

    

    

  • 这种机制提供了编译时类型安全，并且是动态多态性的强大工具，允许代码安全地区分和操作不同的子类型。
  • 然而，这种处理多态数据的直接、类型安全的方法被 Stroustrup 有意地从 C++ 中省略（Stroustrup 认为 Simula 的 INSPECT 语句破坏了模块化），因此在主流 OOP 中基本上丢失了。

真正的起源：Douglas Ross 和 Ivan Sutherland [00:50:50]

影响链被进一步追溯，揭示了这些基本思想的最终起源。

• Douglas T. Ross（麻省理工学院伺服机构实验室，20 世纪 50 年代） [00:55:19]

  • Douglas T. Ross 是早期计算领域的一位有影响力的人物，他在 20 世纪 50 年代开发了“plexes”的概念。
  • 他在麻省理工学院的工作重点是计算机辅助设计 (CAD)，旨在将人类的描述转化为制造的零件。
  • Ross 批评了列表处理语言（如 Lisp）低效的两组件列表结构，提倡使用 plexes，它是具有固定大小的结构化数据，可以实现复杂实体的直接存储和更快的处理。

    

  • Plexes 包含数据成员、指针，以及至关重要的函数指针，从而允许动态行为（早期的虚函数）。

    

  • 这项早期的 CAD 工作涉及具有动态分派机制的直接的、面向数据的表示，从根本上不同于后来的面向对象的封装模型。

• Ivan Sutherland（麻省理工学院林肯实验室，1960 年）和 Sketchpad [01:06:48]

  • Ivan Sutherland 在麻省理工学院林肯实验室工作，创建了 Sketchpad 作为他博士论文的一部分（于 1963 年发表）。

    

  • Sketchpad 是一个革命性的交互式图形程序，运行在 TX-2 计算机上（当时少数几台带有显示器的计算机之一）。

    

  • Sutherland 直接向 Douglas Ross 咨询了 CAD 系统的数据建模，采用了 Ross 的“n 组件元素”（plexes）。
  • 该程序展示了开创性的交互功能，如移动和修改绘制的元素而无需擦除，以及动态约束满足（例如，使线条垂直）。

    

    

  • Sutherland 的约束求解器是“全知的”，通过其共享的内存空间迭代并直接操作组件，展示了巨大的力量和灵活性。

    

    

  • 演讲者强调，Sketchpad 的架构，特别是其对组件的“全知”处理，是现代 ECS 的前身，但其真正的力量被随后的 OOP 先驱所忽视。Alan Kay 本人也注意到 Sketchpad 的强大功能，但专注于“消息传递”和封装的对象，而不是底层数据结构和全局访问。

演讲者个人遇到的“错误” [01:19:47]

Casey Muratori 分享了他在 1997 年遇到的“错误”的个人经历。

• 开发“Negaman”[1997] [01:20:29]
  • 作为一名年轻、缺乏经验的程序员，Casey 的任务是为一个游戏创建一个关卡编辑器，其中涉及“球体上的 CSG”（后来的“负元球”）。

    

  • 他为此任务创建了一个名为“Negaman”的建模器。

    

  • 他试图使用当时流行的编译时 OOP 层次结构（如 C++ 中的那些）来实现基于选择的 UI。

    

  • 这导致了一个极其复杂和混乱的代码库（例如，具有回调的“属性宇宙”的并行层次结构，以获取/设置数据），试图处理跨选定对象的多态交互。

    

    

  • 他事后意识到，他实际上是在尝试实现一个实体组件系统，而不知道它，与他所学的僵化的 OOP 范例作斗争。

    

  • 他将自己效率低下的实现与 Sketchpad 和 Looking Glass 的 ECS 中找到的优雅解决方案进行了对比，感叹知识的流失。

持久的影响和前进的道路 [01:46:58]

• 继续循环 [2025] [01:47:04]

  • Sketchpad 和 ECS 之间的 35 年差距代表着架构演变的一个错失的机会。

    

  • 现代 OOP 教程仍然主要教授直接映射领域模型的有问题的编译时层次结构（例如，IronMan 扩展 IronMan，Vehicle 扩展 Car，Bicycle 扩展 MountainBike）。
  • 这使得架构方法往往过于工程化，并且对于许多常见问题效率较低。

• 危险的隐喻 [01:48:50]

  • 核心问题是“最危险的隐喻是那些看起来在一段时间内有效，因为它们可以阻止更强大的洞察力涌现”。
  • 直观但僵化的编译时 OOP 层次结构，虽然对于简单的情况看起来可行，但抑制了对更灵活的、面向数据的架构的更广泛的理解和采用，而这些架构实际上是在几十年前发现的。
  • 基于现实世界对象的严格封装（受到分子生物学和分布式系统背景的影响）阻止了对更广泛地访问和操作数据的“全知”系统的接受。

问答：更多见解 [01:50:11]

演讲者回答问题，提供更多背景信息和个人反思。

• Looking Glass 向 ECS 的演变 [02:03:33]
  • Ultima Underworld 实体是“胖结构体覆盖层”（联合覆盖层），用于提高内存效率，从而导致了错误（例如，由于燃料覆盖 HP，空的灯笼消失了）。

    

  • Marc LeBlanc，一位关键的实施者，直接遇到了这些错误。

    

  • 此类覆盖层需要手动检查以防止出现问题。

    

  • 对于 System Shock，他们转向了一种“外链接”结构，其中实体具有一个共享的基础和一个指向扩展数据块的指针。这减少了内存碎片并提供了一定的类型安全，但限制了组合的可能性。

    

    

    

  • Flight Unlimited 由于大量使用 C++ new/delete 而面临严重的内存碎片问题，导致强制重新启动游戏（“燃料耗尽”消息）。

    

    

    

  • 臭名昭著的“燃料耗尽”消息实际上是内存碎片的一个指示，提示重新启动游戏。

    

  • 这些现实世界的性能和内存问题促使 Looking Glass 团队在 Thief 中创新并朝着实体组件系统发展。
  • Tom Leonard 被认为是 ECS 的关键见解：从 entity.getHitPoints() 转移到 hitPointsSystem.getEntityHitPoints(entityID)，允许系统有效地迭代特定组件并管理任意大小的属性，同时仍然允许设计人员在运行时定义类型。

    

  • 他们的动机包括避免碎片、支持任意大小的属性、启用运行时类型以及确保尽可能快的性能。