组合模式的核心接口设计是定义抽象基类统一叶子与组合节点的operation()和子节点管理方法，其中子节点管理仅由组合类实现，叶子类抛异常；子节点用智能指针管理，优先unique_ptr；operation()需递归调用以保证透明性；应避免dynamic_cast，通过虚函数封装类型差异。
什么是组合模式的核心接口设计
组合模式的关键在于让单个对象和组合对象对外呈现统一接口。C++里最直接的做法是定义一个抽象基类，所有叶子节点和容器节点都继承它。这个基类必须包含两个核心能力：执行操作（比如 operation()）和管理子节点（比如 add()、remove()、get_child()）。注意，叶子节点的 add() 或 remove() 通常应抛出异常或直接忽略——不是所有实现都适合返回 void，尤其当调用方误把叶子当容器时，静默失败反而更难调试。
常见错误是把 add() 声明为纯虚函数，结果叶子类被迫实现无意义逻辑。更合理的做法是只在组合类中实现子节点管理，叶子类留空或抛出 std::runtime_error("not supported")。
如何安全地管理子节点的生命周期
子节点通常以智能指针形式存储，但选 std::unique_ptr 还是 std::shared_ptr 取决于所有权模型。如果组合对象完全拥有子节点（典型场景），用 std::vector<:unique_ptr>></:unique_ptr>；若多个地方需共享同一子节点（如 DAG 结构），才考虑 std::shared_ptr。混用会导致析构顺序混乱或循环引用。
容易踩的坑：
- 用裸指针 +
new手动管理 → 忘记delete或异常中途跳出导致泄漏 - 在
Composite的拷贝构造函数里浅拷贝子节点指针 → 后续析构重复释放 - 子节点类型硬编码为具体类（如
std::vector<:unique_ptr>></:unique_ptr>）→ 破坏多态，无法添加新组件类型
为什么 operation() 在组合类里要递归调用
因为组合模式的本质是“透明性”：客户端不关心当前对象是叶子还是容器，统一调用 operation() 即可触发整棵树的行为。所以 Composite::operation() 必须遍历所有子节点并调用其 operation()。这看似简单，但实际要注意：
性能影响：
- 递归深度过大可能栈溢出（>1000 层需改用显式栈模拟）
- 频繁虚函数调用有间接跳转开销，高频路径可考虑模板化或扁平化结构（但会牺牲灵活性）
兼容性方面，C++17 的 if constexpr 无法在此处优化掉虚调用，因为类型在运行时才确定。
怎么避免动态_cast 和运行时类型检查
组合模式下不该出现 dynamic_cast —— 如果你发现自己在写 if (auto<em> p = dynamic_cast<composite>>(ptr)) { ... }</composite></em>，说明接口设计已偏离初衷。正确做法是把需要分支处理的操作上提到基类中作为虚函数，比如：
virtual bool is_composite() const { return false; }
// Composite 重写为 return true;
或者更进一步，把行为差异封装进虚函数，例如 accept(Visitor&) 配合访问者模式。强行用 typeid 或 dynamic_cast 判断类型，等于放弃多态，回到面向过程的老路。
组合模式真正难的不是写几行虚函数，而是判断什么时候不该用它：当树形结构不稳定、节点类型频繁增删、或操作逻辑高度异构时，硬套组合模式反而让代码更难维护。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
