1 · 读书笔记：DOD#

https://www.dataorienteddesign.com/dodbook/

• What: 一种以数据的真实特征（类型、数量、频率、形状、概率）和目标硬件约束为出发点来设计数据布局与变换的软件方法论。
• Why: OOP 把问题域概念编码进数据结构，导致数据与含义耦合——缓存不友好、难以并行、需求变更时牵一发动全身；DOD 将数据与含义解耦，让布局服务于硬件、变换服务于当前需求。
• How: 把数据从对象图中剥离、用关系模型范式化为线性表、按访问模式拆分 hot/cold、用”存在即处理”替代分支、用组件管理器替代实例更新——始终针对具体数据的具体特征做设计，拒绝通用化框架。

1.1 · 核心观点：

软件设计应以数据的布局与变换为中心，而非以问题域的对象建模为中心。理解数据的类型、数量、频率、形状和概率，结合目标硬件特性来组织数据和编写变换，才能获得高性能、易维护、可演进的系统。

两大基本原则：

1. 数据不是问题域（Data is not the problem domain）——数据本身没有意义，意义是我们赋予的。不要把问题域的概念硬编码进数据结构，否则你会得到 “你想要一根香蕉，结果拿到了拿着香蕉的大猩猩和整个丛林”。
2. 数据即类型、频率、数量、形状和概率（Data is the type, frequency, quantity, shape, and probability）——DOD 不只是关于 cache miss，更关于真实运行时数据的统计特征。用真实数据的模式驱动算法选择，而非用抽象的泛化方案猜测未来。

1.2 · 启发点（关键洞察）：

1. 关系模型是整理游戏数据的利器——把复杂的对象图/层级结构做数据库式的范式化（1NF→BCNF），消除 NULL、消除重复、消除多值字段，你会得到干净的线性数组，天然适合批量处理和缓存友好。
2. 组件化 → 管理器驱动 → 实体消失——从单体 Player 类拆出组件，再让管理器按组件类型批量更新，最终实体只是组件的组合，不再需要一个 “Player class”。这打开了并行处理的大门。
3. 层级细节度（Hierarchical LOD）不只是图形概念——可以用在 AI、游戏逻辑、甚至 UI 上。核心度量不是距离，而是玩家感知占比。“Collective lodding” 让一万架飞机可以只用几个 wave 实体表示，直到靠近才展开。
4. JIT Memento——用确定性种子（如位置坐标、车牌号）生成伪随机细节，不存储却可重复还原。无内存开销，无生命周期管理。
5. 存在即处理（Existential Processing）——用数据的存在与否代替 bool/enum 分支。把 if (isAlive) 变成 “alive 表里有这条数据”，消除分支、简化调试、天然并行。
6. 帮助编译器——减少内存依赖链（避免指针追踪）、利用 cache line 剩余空间缓存常见查询结果、注意 aliasing/false sharing/分支预测，都是低成本高回报的实践。
7. OOP 最大的问题是应对变化——OOP 擅长处理底层实现变更，但面对需求/设计层面的变化（频率更高、影响更大）时非常脆弱，因为它把数据和含义绑定在了一起。DOD 把数据和含义解耦，重构变得廉价甚至不需要。

1.3 · 行动：

1. 审视当前项目中的 “God Class”（如 Player/Entity），尝试用组件拆分 + 管理器批量更新的模式重构。
2. 对热路径数据做范式化分析：哪些字段总一起读？哪些只写不读？按 hot/cold 拆分结构体。
3. 遇到 if (hasX) 式分支时，思考能否用 “存在即处理” 替代——把数据放进对应的表，不在表里就是没有。
4. 在需要大量同类实体的场景（粒子、NPC、库存物品），用 collective lodding 思维：位置拥有小麦，而非小麦拥有位置；用数量而非实例。

1.4 · 金句：

1. “Data is all we have. Data is what we need to transform in order to create a user experience.”
2. “You wanted a banana but what you got was a gorilla holding the banana and the entire jungle.” —— Joe Armstrong
3. “Data-oriented design is the practice of designing software by developing transformations for well-formed data where the criteria for well-formed is guided by the target hardware.”
4. “The wheat doesn’t have positions. The positions have wheat.”
5. “Future-proof systems rarely are.”
6. “Level of detail should be defined by how the player perceives a thing, at the range it is at.”
7. “If state is a function of other state, then it’s less prone to inconsistency.”