14. Component

为什么"14. Component"从问题证据开始

你的游戏有个"机器人"实体：要接收输入、做物理碰撞、渲染模型、播放音效。最直觉的 OOP 做法是把所有能力写进一个 Robot 类——输入处理、物理、渲染、音频逻辑全在一个类里。代码今天能跑，但很快这个类膨胀成几千行的"上帝类"：改一处物理，渲染逻辑在旁边碍事；要加新实体（带不同能力组合），只能复制粘贴整个类再删掉不要的部分。

本页把"无模式基线"定义为"单个实体一个上帝类"的代码，然后引入组件作为候选机制，验证它是否真的让"实体能力可独立增删组合"。通过条件是新增一种实体 = 组合不同组件，不复制代码——而不是每个实体一个不可分割的巨类。

🔮 先预测："会飞的鱼"用继承树表达需要几层，用组件需要几次装配？

来源、版本与独立重写边界

本页用作者完整在线正文核对正式标题、设计分叉和时代语境，并以作者源码仓库交叉检查结构。仓库许可证明确正文、HTML与样式为 CC BY-NC-ND 4.0，示例程序等其他文件为 MIT；因此下列中文解释、图示、交互和代码均为独立教学重写，不翻译、拼接或改写受 ND 限制的原文表达。

本章机制与术语

理解 Component 需要四个核心概念：

• 组件（component）：封装一个领域能力的类（输入/物理/渲染/音频），有独立的 update/render 接口。
• 实体/容器（entity/container）：持有组件列表的对象——本身不做行为，只管理组件生命周期。
• 组合（composition）：实体按需装配组件——能力 = 组件集，新实体 = 新组合。
• 消息转发（message forwarding）：组件间通信经容器转发，组件互不直接引用——解耦关键。

四个概念共同约束"把单个实体跨越的输入、物理、渲染和音频领域拆成组件"：任何结论都必须回到"能力能否独立增删、组件是否互不耦合、新实体是否零复制"三个可观察量。

💡 对着动画看：动画中央是 GameObject 容器（外框），内部六格是组件（Input/Physics/Graphics/Audio/Health/AI），右侧"组合 vs 继承树"对比框。注意容器本身不做行为——它只是组件的家。读"戈耳狄俄斯之结"一节时，想象一个同时需要"会飞 + 会游泳 + 会攻击"的实体，组合怎么比继承树简单。

官方结构逐项深读

14. Component

Component 的主张：把实体的每个领域能力拆成独立组件，实体成为组件的容器。一个"会走路的机器人" = 输入组件 + 物理组件 + 渲染组件 + 音频组件。每个组件只管自己的领域，实体只负责持有它们并转发消息。新增实体 = 重新组合组件；新增能力 = 写新组件挂上——组合优于继承。

Intent

意图：把"实体是什么"（组件集合）与"每个领域怎么做"（组件实现）分离。实体成为薄容器，领域逻辑下沉到各自组件。这带来三个能力：能力可独立增删（挂/摘组件）、能力可跨实体复用（同一组件挂到不同实体）、能力可独立测试（组件单测）。这是"高内聚低耦合"在实体层面的落地。

Motivation

回到机器人：一开始只是"能走动"，后来要"能射击"，再后来"能听指令"。每次加能力都往 Robot 类里塞代码——类越来越大，改动越来越危险（改物理可能踩到渲染的变量）。动机就是让"加能力"不再等于"改巨类"——每个能力一个组件，加能力 = 加组件，互不干扰。

The Gordian knot

"戈耳狄俄斯之结"比喻：实体同时依赖输入、物理、渲染、音频——这些领域交织成一个解不开的结。继承树解不开它（"会飞的鱼"要继承到什么位置？），复制粘贴解不开它（改一处要同步多处）。这个结的解法不是"更聪明地继承"，而是把结剪开——按领域切开成独立组件。

Cutting the knot

剪开结：把 Robot 类按领域切成四个类——InputComponent（输入）、PhysicsComponent（物理）、GraphicsComponent（渲染）、AudioComponent（音频）。每个类只依赖自己的领域（输入组件认识键盘，不认识渲染）。Robot 变成容器，持有这四个组件的实例。类从"一个巨类"变成"一个容器 + 四个小类"——每个小类都可独立理解、测试、替换。

Loose ends

剪开后的"松线头"：组件之间怎么协作？物理组件更新了位置，渲染组件怎么知道？直接互相调用会让组件重新耦合。解法：组件不直接互相引用，通过容器转发——物理组件调 container.sendMessage(类型, 数据)，容器分发给关心此消息的组件。组件之间保持陌生，耦合只存在于"组件 ↔ 容器接口"。

Tying back together

重新"系起来"：容器统一管理组件生命周期（attach/detach/update），组件通过容器协作。实体对外仍是一个整体（外部只跟实体说话，不跟组件说话），内部是解耦的组件网。外部接口稳定（实体），内部结构灵活（组件）——这正是组件模式"既解耦又统一"的精妙。

The Pattern

模式结构：Component 抽象基类（virtual update(dt) = 0、virtual render() = 0）→ 具体组件（InputComponent、PhysicsComponent……实现各自领域）→ Container 类（持有 Component* 列表，update() 遍历调组件 update，add/remove 管理组件）。实体 = Container + 组件集。引擎只认识 Container，不关心具体组件——新增组件类型不影响引擎。

When to Use It

何时用组件：实体能力多样且组合多变（游戏对象：玩家/敌人/道具需要不同能力组合）、能力需要跨实体复用（同一渲染组件挂到所有可渲染实体）、能力需要独立演进（物理引擎升级只改物理组件）。何时不用：实体能力单一固定（一个类够了）、组合需求简单（继承够用）。判断标准："实体的能力集合是否经常变化"——是，用组件。

Keep in Mind

组件模式的注意点：组件数量与粒度（组件太细→实体组件列表爆炸；太粗→组件又变巨类——按"变化频率独立"切分）、组件间通信成本（消息转发比直接调用慢，高频交互要优化）、容器职责膨胀（容器可能变成"万能中转站"——保持薄，只做转发不做事）。

Sample Code

示例代码：Bjorn 实体 = InputComponent + PhysicsComponent + GraphicsComponent + AudioComponent。Bjorn::update(dt) 遍历组件逐个 update；组件持有 Bjorn* 引用以便访问共享状态（如位置）。一个"机器人"的完整结构：输入组件读键盘→设速度，物理组件用速度更新位置，渲染组件用位置画模型——各管各的，通过 Bjorn 共享位置。

A monolithic class

对照实现：单体的 Bjorn 类把四个领域全写进去——update(dt) 里先读输入、再算物理、再更新动画、再播音效，四段逻辑挤在一个方法里。改物理要小心动画变量，加能力要重写整个类。这个"能跑但难改"的基线，正是组件模式的出发点——对照它才能体会拆分的价值。

Splitting out a domain

拆分第一步：把最独立的一个领域抽出来做组件——比如 InputComponent。它只关心"读输入、改目标速度"，完全不碰渲染。抽一个组件就少一块耦合：之后的物理、渲染改动不会再踩到输入逻辑。拆分要渐进——先抽最独立的，验证可行再继续，别一次拆到底。

Splitting out the rest

继续拆：物理组件（用速度更新位置）、图形组件（用位置渲染）、音频组件（触发音效）。每个组件只依赖共享状态（位置/速度）和容器接口，互不引用。拆完再看：Bjorn 类的 update 变成三行（遍历组件），所有领域逻辑都在各自组件里——类瘦身完成，领域各归其位。

Robo-Bjørn

组合的威力：同一组件装配出不同实体——RoboBjorn = 输入 + 物理 + 图形 + 音频 + 武器组件；StaticBjorn = 只有图形（雕像）。组件复用：武器组件、图形组件在多个实体间共享，写一次用多处。新增实体不再是"复制类再删代码"，而是"声明组件清单"——配置化组合。

No Bjørn at all?

组件模式的极致：连实体类都可以是通用的——Entity 就是"组件容器 + ID"，所有实体共用同一个类，区别只在挂的组件。玩家、敌人、道具都是同一个 Entity 类的实例，组件列表不同。这走向 ECS（实体-组件-系统）：实体纯数据容器，组件纯数据，行为移到系统。组件模式是 ECS 的思想前身。

Design Decisions

两个关键设计决策：实体怎么获得组件（硬编码构造 vs 数据配置）和 组件怎么通信（直接引用 vs 消息转发）。前者决定组合的灵活性，后者决定耦合度——下面两节展开。

How does the object get its components?

组件来源：硬编码（实体的构造函数里 add(new PhysicsComponent)——简单直接，但换组合要改代码）与数据配置（实体由数据文件描述组件清单——策划可配置，与 Prototype/Type Object 呼应，是 ECS 的方向）。作者建议：从硬编码起步（代码里声明组合，最快见效），组合需求多样化后再上数据配置。

How do components communicate with each other?

组件通信：直接引用（组件持有对方指针，physics_->position——快，但组件互相认识，耦合回来）与消息转发（组件调 container->send(msg)，容器分发给订阅者——解耦，但多一层间接、消息要定义格式）。作者建议：默认直接引用共享状态（通过容器持有公共状态对象，组件读写它），真正需要"事件通知"时再用消息——避免为解耦而解耦。

See Also

• Type Object：类型对象定义"实体是什么"（种类），组件定义"实体能做什么"（能力）——数据与行为互补。
• Update Method：组件的 update(dt) 接口与 Update Method 完全一致——组件是"带领域的实体更新片段"。
• Subclass Sandbox：沙箱用继承给子类能力，组件用组合给实体能力——继承与组合的对比案例。

可迁移实现或计算骨架

initial state -> 识别实体的独立领域 -> 每领域一个组件类 -> 实体容器持组件列表 -> update 遍历组件 -> 组件经容器协作
fault injection -> 单个实体一个上帝类
pass condition -> 新增实体=重新组合组件、组件互不耦合、新能力零复制
reset -> initial state

对应实现要点：Component 抽象基类声明 update/render；具体组件各管一域、只依赖共享状态；实体容器管理组件生命周期与消息转发；组合从硬编码起步，需要时上数据配置。该骨架只保存实验合同；真实项目还要固定组件清单、共享状态对象与消息格式，并保留基线实现以便回退。

本章练习与节点验证矩阵

术语复核

练习答案参考

练习判据即答案：每个练习的"验证判据"列给出了通过标准——先自己动手，再对照判据核验。

术语复核与本章回顾

掌握"14. Component"意味着能从"单个实体一个上帝类让能力增删困难"出发，解释组件、实体容器、组合与消息转发四者的关系，再用"能力能否独立增删、组件是否互不耦合、新实体是否零复制"三个可观察量推翻或保留实现。若三个判据不能同时满足，本章仍未通过。

一句话回顾：实体是组件拼出来的，不是继承出来的——每个领域一个组件，容器管生命周期，新能力挂新组件，上帝类与继承树一起被剪断。

阅读导航

← 上一页：V. Decoupling Patterns · 下一页：15. Event Queue → ← 上一页：V. Decoupling Patterns · 下一页：15. Event Queue →