环形耦合（circular coupling）指两个或多个模块/类通过直接引用、实例持有或互相依赖接口形成闭环依赖，例如 a 持有 b 的实例，b 又持有 a 的实例，或 a 依赖 b 的头文件，b 又依赖 a 的头文件。这类结构在 c++ 中极易引发编译失败、初始化顺序问题、难以单元测试、无法独立演进等质量风险。模块化重构不是简单“拆文件”，而是通过职责重划、边界厘清和通信机制升级，从根源切断循环依赖链。

识别并打破环形依赖的物理路径

环形耦合往往藏在头文件包含关系或构造函数注入中。先用工具（如 include-what-you-use、Clang’s dependency graph）生成依赖图，定位闭环节点。常见模式包括：

头文件互相 #include：将共用类型（如枚举、数据结构）抽离到独立的 公共契约头文件（如 common_types.h），A 和 B 都只包含它，不再互含

类 A 在头文件中声明 std::unique_ptr<B>，B 同样持有 A：改为前向声明（class B;）+ 指针/引用成员，把具体类型依赖推迟到实现文件（.cpp）中

构造函数相互注入对方实例：引入第三方协调者（如 Orchestrator 类）或使用工厂函数延迟创建，避免构造时强绑定

用接口抽象替代具体类型依赖

环形耦合的本质是模块间知道得太多。让 A 不再依赖 class B，而是依赖一个仅定义所需行为的 IBObserver 接口；B 同理依赖 IAPublisher。这样双方只面向契约，不关心对方是谁。

接口定义放在独立头文件（如 observer_interface.h），由被依赖方（B）实现，依赖方（A）仅包含该接口

实现类与接口分离：B 的具体实现（BImpl）在 .cpp 中完成，不暴露给 A

配合依赖注入：A 的构造函数接收 std::shared_ptr<IBObserver>，运行时由容器或工厂传入，而非自行 new B

引入事件或消息机制解耦双向调用

当 A 需通知 B 状态变更，B 也要反馈结果给 A，硬编码双向调用必然成环。改用发布-订阅模型，让双方只与事件总线通信。

‎ Gemini Storybook

‎ Gemini Storybook

Google Gemini推出的AI绘本生成工具

下载

定义轻量事件结构（如 struct UserUpdatedEvent { int user_id; };），不带业务逻辑

A 触发 event_bus.publish(UserUpdatedEvent{123})，B 订阅该事件并响应；B 的响应（如 UpdateConfirmedEvent）也走同一总线，A 订阅即可

事件总线（如基于 std::function 的简单实现或成熟库如 Boost.Signals2）作为第三方中介，消除 A 与 B 的直接引用

合并高频交互模块，避免“为解耦而解耦”

有时环形耦合反映的是职责划分过细。若 A 和 B 总是一起创建、生命周期一致、交互极其频繁（如 UI 组件与其控制器），强行拆分反而增加间接层和性能损耗。

评估二者是否属于同一业务语义域（例如 “订单编辑界面” 与 “订单验证逻辑” 天然一体）

合并为单一模块（如 OrderEditor），内部高内聚，对外只暴露统一接口（submit(), cancel()）

合并后，原环形依赖消失，代码更易理解、调试和测试