HackerObject-Oriented Programming is Bad
Brian WillYouTube ↗
延伸阅读 2
字幕解读
Brian Will 将面向对象的主要问题定位在行为与数据类型的细粒度绑定：新增或改变数据类型时，相关行为要分散修改，封装反而制造耦合。他偏好以普通数据和过程式函数组织多数程序，必要时用参数传递依赖、用纯函数降低状态交互，并用较粗粒度模块封装。演讲也承认类、抽象数据类型和测试仍有合适场景。
自动字幕 · 引文按字幕原文展示，可点时间戳回看片段。
内容要点
- 演讲批评的是把行为绑定到许多具体数据类型所产生的改动负担，而非类或抽象本身。
- 普通函数和显式参数可减少跨对象状态依赖；避免把程序切成过多微小单元。
- 封装仍有用，但应围绕稳定边界和整体模块，而不是把每个数据类型都当行为容器。
视频章节 6
- 问题不在于类本身
- 类型与行为绑定
- 函数和数据的组织
- 共享对象与状态
- 过程式替代及其边界
- 封装粒度与横切关注点
具体观点与证据 4
细粒度对象封装并未消除多个对象间共享可变状态的协调问题。
讲者批评细粒度封装，不等于否定所有模块边界。
as soon as you have objects being shared encapsulation just flies out the window强行将每种行为归给一种数据类型会制造缺少实际数据意义的类。
针对把所有行为都做成方法的设计规范。
they exist simply as attacks to conform to this ideology about code modularization把长逻辑切碎未必降低总复杂度，也可能只是把复杂度分散。
复用或隔离复杂逻辑仍是抽函数的理由。
are we actually decreasing the total complexity of our program or just displacing the complexity纯函数容易独立理解，因为推理无需考虑外围状态。
讲者同时提醒效率和适用范围。
the brilliant thing about pure functions is that they're the only truly self-contained unit of code补充字幕原文 2
作者明确把问题放在某类组织耦合上，而非直接否定类。
the problem is really not classes per se围绕数据类型绑定函数会令类型变化牵动相关行为。
association between certain functions and certain data types解读边界
这是对常见 OOP 组织方式的批判性演讲，例子偏向作者选择的代码结构；结论不证明过程式设计总是更优，也没有系统比较大型团队下的模块化代价。