组合模式常见错误有哪些

组合模式（Composite Pattern）是一种结构型设计模式，用于将对象组合成树形结构以表示“部分-整体”的层次结构，使客户端对单个对象和组合对象的使用具有一致性。尽管组合模式很常用，但在实际应用中容易出现一些典型错误。以下是组合模式的常见错误及分析：

一、错误地将叶子节点当成组合节点使用

错误表现

• 叶子节点（Leaf）也实现了 add()、remove()、getChild() 等方法
• 客户端对叶子节点调用这些方法时，要么什么都不做，要么抛异常

示例

class File implements Component {
    void add(Component c) {
        throw new UnsupportedOperationException();
    }
}

问题

• 违背接口隔离原则
• 客户端无法安全使用统一接口
• 容易在运行时出错

正确做法

• 叶子节点不提供这些无意义的方法
• 或使用透明模式 vs 安全模式明确选择

二、混淆“透明模式”和“安全模式”

两种模式对比

常见错误

• 想“既安全又透明”，结果两头不讨好
• 客户端代码里大量 instanceof

建议

• 业务简单、树结构稳定：用透明模式
• 叶子节点多、结构复杂：用安全模式

三、组合结构变成“图”而不是“树”

错误表现

• 子节点被多个父节点引用
• 形成循环引用

A
└── B
    └── A (循环)

后果

• 遍历死循环
• 内存泄漏
• 逻辑混乱

正确做法

• 明确组合是树结构
• 添加子节点时检查父节点
• 删除父节点时清理引用

四、在组合节点中滥用继承

错误表现

• 让 Composite 继承 Leaf
• 或让 Leaf 继承 Composite

问题

• 继承关系错误
• 破坏组合语义

正确做法

• 使用组合而非继承
• 共同接口 / 抽象类

五、组合对象与业务对象耦合过深

错误表现

• Component 接口中包含大量业务逻辑
• 组合结构变成“万能容器”

问题

• 组合模式变成“上帝对象”
• 难以扩展和维护

正确做法

• 组合模式只负责结构
• 业务逻辑放到具体组件中

六、忽略递归带来的性能问题

错误表现

• 在组合节点中递归遍历整棵树
• 每次操作都从头遍历

问题

• 性能差
• 栈溢出风险

优化建议

• 缓存计算结果
• 限制递归深度
• 使用迭代方式遍历

七、客户端过度依赖组合结构细节

错误表现

if (component instanceof Composite) {
    ...
}

问题

• 破坏组合模式“一致性”的核心思想
• 增加耦合

正确做法

• 客户端只依赖 Component 接口
• 使用多态完成操作

八、误用组合模式

组合模式不适合的场景

• 对象之间没有“部分-整体”关系
• 结构非常扁平
• 子节点类型差异极大

错误后果

• 强行套模式
• 代码反而更复杂

九、忽略空对象或默认行为

错误表现

• 叶子节点方法直接抛异常
• 客户端必须处理异常

改进

• 使用空对象模式
• 或提供默认实现

总结：组合模式的核心陷阱

组合模式最大的错误，是让“结构”承担了不该承担的责任。

常见错误一句话总结：

• ❌ 叶子节点装成组合节点
• ❌ 树变成图
• ❌ 滥用继承
• ❌ 模式与业务耦合
• ❌ 客户端破坏一致性

如果你愿意，我也可以：

• 用 Java / C++ / Python 举例说明
• 对比组合模式 vs 装饰器 / 访问者模式
• 结合真实业务场景（如菜单、文件、组织架构）分析