- Published on
【Data-oriented Programming】把代码和数据分开
- Authors
- Name
- 小土刀
- @wdxtub_com
省流版：把代码和数据分开，是降低系统复杂度的第一步。
对象导向编程（OOP）就像是一个擅长“打包销售”的商人，把数据塞进类里、方法粘在对象上，然后套个继承链。乍一看，结构清晰；再一看，天书一卷。
面向数据编程（Data-Oriented Programming, DOP）想说的却是另一件事：
👉 让代码只是代码，让数据只是数据。
把这两者分开，好处不是“哲学上更优雅”，而是系统会因此变简单、可测试、更稳定，甚至跑得更快。这不是“风格之争”，而是复杂度管理的现代方法论。
为什么要把代码和数据分开？
我们来先看看对象导向的“问题合集”：
- 类是个数据黑箱，debug 像开盲盒；
- 方法和数据捆绑，变动一处牵一身；
- 类的继承链越长，认知负担越大；
- 在并发环境里，需要自己手动加锁；
- 想把数据导出来用个 JSON，还得自定义序列化逻辑。
以上种种，其实都是**“耦合过重”的后果**。
而把代码和数据分离后，系统会变成这样：
| 特性 | 分离前（OOP） | 分离后（DOP） |
|---|---|---|
| 代码组织 | 类 + 方法 | 模块 + 纯函数 |
| 数据结构 | 封装在对象中 | 独立的通用数据结构（如 map/list） |
| 状态管理 | 对象内部变化 | 数据不可变 + 结构共享 |
| 并发控制 | 显式加锁 | 乐观并发控制 + 原子操作 |
| 数据验证 | 类中写死校验逻辑 | JSON Schema 分离表示与验证 |
面向数据的 4 条基本原则
✅ P1. Separate code from data
用函数处理数据，用 map 存储数据。两者保持“君子之交”，好聚好散。
✅ P2. Represent data with generic structures
把字段存在 map 里，字段名就是字符串，写个通用处理函数就能跑全场。
✅ P3. Data is immutable
数据一经生成不再改变。修改数据 ≈ 创建新版本。好处包括：
- 不用担心谁悄悄改了你手里的数据；
- 多线程读写也不怕死锁；
- 快速 diff 和缓存结构更新变得可能。
✅ P4. Separate schema from representation
数据的结构用 JSON Schema 表示，验证逻辑和业务代码解耦，不仅能校验，还能生成图谱。
真正的“低代码”，不是拖拽，而是抽象
有些人说面向数据编程“太通用了，没类型不安全”，但真相是：
- 开发初期更快：不需要设计一堆类和接口，字段变动也不破坏整体结构。
- 系统边界更清晰：代码处理数据，数据通过 schema 管理，清晰分工。
- 测试更容易：函数是纯的，输入输出确定，测试只围绕数据即可。
- API 更好配：数据天然就是 JSON-friendly，做成服务或导出接口极其顺滑。
这不是架构师炫技，而是实用主义者的胜利。
真正简单的系统，不是“什么都能做”，而是“做的事都简单”
在系统设计里，“简单”≠ “少功能”，而是：
- 逻辑拆得开；
- 数据查得到；
- 错误找得到；
- 状态控得住。
而这一切的底层，都离不开一个关键原则：
Separate Code from Data.
愿你在拆开代码与数据的那一刻，也悄悄拆除了系统的一层复杂。