继承体系臃肿源于误用抽象维度，如用继承表达“has-a”关系；应改用组合+接口，将能力拆为独立组件，通过运行时装配、Pimpl隔离和注册表管理实现解耦与安全迁移。
为什么继承体系会“臃肿”而不是“强大”
继承本身不导致臃肿，但当它被用来表达“has-a”“uses-a”或临时拼凑逻辑时，就会快速滑向失控。典型症状包括：基类塞满virtual函数却只被 20% 的子类重写；派生类构造函数里堆砌 5 个布尔参数控制行为分支；dynamic_cast 频繁出现且失败后无 fallback；修改一个子类的 protected 成员，引发 7 个其他子类编译失败。这些不是继承用得深，而是用错了抽象维度。
用组合 + 接口替代“深度继承链”
把“形状类继承树”这种经典例子换成真实场景：一个嵌入式网关项目中，DeviceBase 派生出 LoRaDevice、CellularDevice、WiFiDevice，每个又各自再派生出 SecureLoRaDevice、OTAEnabledCellularDevice……最终形成 4 层继承、12 个类、共用 3 个全局状态变量的结构。
重构动作不是删掉继承，而是把“通信能力”“安全策略”“固件升级支持”拆成独立组件：
-
Device类不再继承，只持有一个std::vector<:unique_ptr>> - 每个组件实现统一接口（如
Component::init()、Component::handle_event()） - 运行时按需添加：比如仅在 LoRa 设备上 attach
LoRaRadioComponent和AES128EncryptionComponent，而 WiFi 设备换用WPA3AuthComponent - 移除所有
protected成员变量——状态完全归属组件内部，Device只负责调度和生命周期
如何安全迁移而不中断现有功能
关键不是一步到位，而是让新旧机制并存、可验证、可灰度。具体操作包括：
- 先为每个现有派生类写一个对应的
LegacyAdapter组件，把原类对象包装进去，实现标准Component接口，确保调用路径不破 - 在
CMakeLists.txt中用option(ENABLE_COMPONENT_ARCH "Use component-based arch" OFF)控制编译开关，老代码走原路径，新模块走组件路径 - 对每个组件编写最小闭环测试：例如
TEST(LoRaRadioComponent, SendsPacket)不依赖Device类，只构造组件、注入 mock radio driver、断言发送缓冲区内容 - 禁止跨组件直接访问成员——所有交互必须通过明确的
Event或Message对象，用std::variant封装类型，避免dynamic_cast回潮
Pimpl + 组件注册表解决头文件爆炸与编译依赖
组件化后容易陷入另一个陷阱：每个组件头文件 include 一堆依赖，改一个 LogComponent.h 导致全量重编。这时要立刻引入两层隔离：
- 对外暴露极简接口头文件（如
include/components/log.hpp），只声明class LogComponent前向声明 + 工厂函数make_log_component() - 实现全部挪到
src/components/log_impl.cpp，内部用Pimpl惯用法隐藏spdlog::logger、std::mutex等细节 - 用静态注册表管理组件类型：
ComponentRegistry::register_type，运行时通过字符串名创建实例，彻底解除头文件耦合("log")
最容易被忽略的是组件间时序依赖：比如 ConfigComponent 必须在 NetworkComponent 初始化前就加载完成。这无法靠编译器检查，必须在启动阶段显式调用 registry.startup_order({{"config", 0}, {"network", 1}}) 并做校验——否则静默失败比崩溃更难排查。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
