组合模式（Composite）：透明组合模式、安全组合模式、组合模式在文件系统中的应用

组合模式，说白了就是处理「部分-整体」层次结构的一种设计思路。我刚开始接触这个模式时，觉得它不就是个树形结构嘛，有啥好讲的？后来在项目中踩过坑才明白——关键在于让客户端能用一致的方式对待单个对象和组合对象。

举个例子你就懂了。文件系统里，一个文件夹可以包含文件，也可以包含子文件夹。你双击一个文件，系统打开它；双击一个文件夹，系统展开它。对用户来说，操作方式是一样的。这就是组合模式要解决的问题。

组合模式的核心思想

组合模式定义了一个抽象构件（Component），它声明了所有子类共有的接口。叶子构件（Leaf）和容器构件（Composite）都实现这个接口。叶子没有子节点，容器可以包含子节点。

我习惯用一句话概括：让树形结构中的节点和叶子对外表现一致。

核心角色：

  • Component（抽象构件）：定义叶子节点和容器节点的公共接口
  • Leaf（叶子构件）：没有子节点的节点，实现具体行为
  • Composite（容器构件）：有子节点的节点，负责管理子节点

你想想看，如果没有组合模式，客户端调用时就得判断当前对象是文件还是文件夹，然后走不同的逻辑。代码里到处都是 if-else，维护起来很痛苦。

透明组合模式 vs 安全组合模式

这里有个经典的分歧点——到底要不要把子节点管理方法（add、remove、getChild）放在抽象构件里？

两种方案，各有各的坑。我两种都试过，给你说说区别。

透明组合模式

透明组合模式把 add、remove、getChild 这些方法都定义在抽象构件里。叶子节点和容器节点都有这些方法。叶子节点虽然用不上，但必须实现它们（通常是空实现或抛异常）。

优点：客户端完全不用区分叶子还是容器，调用方式完全一致。这就是「透明」的含义。

缺点：叶子节点被迫实现了不该有的方法。如果客户端不小心调用了叶子节点的 add 方法，要么没反应，要么抛异常——这其实违背了接口隔离原则。

// 抽象构件
abstract class FileSystemNode {
    protected String name;
    
    public FileSystemNode(String name) {
        this.name = name;
    }
    
    // 公共方法
    public abstract void display();
    
    // 子节点管理方法——叶子节点也得有
    public void add(FileSystemNode node) {
        throw new UnsupportedOperationException("不支持添加子节点");
    }
    
    public void remove(FileSystemNode node) {
        throw new UnsupportedOperationException("不支持移除子节点");
    }
    
    public FileSystemNode getChild(int index) {
        throw new UnsupportedOperationException("不支持获取子节点");
    }
}

// 叶子节点：文件
class File extends FileSystemNode {
    public File(String name) {
        super(name);
    }
    
    @Override
    public void display() {
        System.out.println("文件: " + name);
    }
    // add、remove、getChild 继承自父类的抛异常实现
}

// 容器节点：文件夹
class Folder extends FileSystemNode {
    private List<FileSystemNode> children = new ArrayList<>();
    
    public Folder(String name) {
        super(name);
    }
    
    @Override
    public void display() {
        System.out.println("文件夹: " + name);
        for (FileSystemNode child : children) {
            child.display();
        }
    }
    
    @Override
    public void add(FileSystemNode node) {
        children.add(node);
    }
    
    @Override
    public void remove(FileSystemNode node) {
        children.remove(node);
    }
    
    @Override
    public FileSystemNode getChild(int index) {
        return children.get(index);
    }
}

我曾经踩过的坑：用透明组合模式时，团队里新来的同事不知道叶子节点不能 add，写了个循环遍历所有节点然后统一 add 子节点。结果文件节点静默失败，排查了半天才发现是叶子节点抛了异常。嗯，从那以后我倾向于在文档里明确标注「叶子节点不支持的操作」。

安全组合模式

安全组合模式把子节点管理方法只放在容器构件里，抽象构件只定义公共业务方法。叶子节点压根没有 add、remove 这些方法。

优点：接口职责清晰，叶子节点不会有不相关的方法。编译期就能发现调用错误。

缺点：客户端需要判断当前对象是叶子还是容器，才能调用对应的方法。说白了，失去了「透明性」。

// 抽象构件——只有公共方法
abstract class FileSystemNode {
    protected String name;
    
    public FileSystemNode(String name) {
        this.name = name;
    }
    
    public abstract void display();
}

// 叶子节点：文件
class File extends FileSystemNode {
    public File(String name) {
        super(name);
    }
    
    @Override
    public void display() {
        System.out.println("文件: " + name);
    }
}

// 容器节点：文件夹——多了子节点管理方法
class Folder extends FileSystemNode {
    private List<FileSystemNode> children = new ArrayList<>();
    
    public Folder(String name) {
        super(name);
    }
    
    @Override
    public void display() {
        System.out.println("文件夹: " + name);
        for (FileSystemNode child : children) {
            child.display();
        }
    }
    
    public void add(FileSystemNode node) {
        children.add(node);
    }
    
    public void remove(FileSystemNode node) {
        children.remove(node);
    }
    
    public FileSystemNode getChild(int index) {
        return children.get(index);
    }
}

我的选择建议：如果系统规模不大，客户端调用逻辑简单，我倾向于用安全组合模式。接口干净，不容易出错。如果系统很复杂，客户端需要大量统一操作树形结构，透明组合模式反而更省事——但一定要在文档里说清楚叶子节点的限制。

组合模式在文件系统中的应用

文件系统是组合模式最经典的案例。每个文件系统都有两个基本元素：文件和文件夹。文件是叶子节点，文件夹是容器节点。

我在项目中做过一个简易的文件管理工具，核心逻辑就是组合模式。来看看实际代码：

// 客户端使用示例
public class FileSystemClient {
    public static void main(String[] args) {
        // 创建文件系统树
        Folder root = new Folder("根目录");
        
        Folder docs = new Folder("文档");
        Folder pics = new Folder("图片");
        
        File readme = new File("README.md");
        File notes = new File("笔记.txt");
        File photo1 = new File("风景.jpg");
        File photo2 = new File("自拍.png");
        
        // 组装树形结构
        root.add(docs);
        root.add(pics);
        
        docs.add(readme);
        docs.add(notes);
        
        pics.add(photo1);
        pics.add(photo2);
        
        // 统一操作——显示整个目录树
        root.display();
        
        // 计算总大小（假设每个文件有大小属性）
        System.out.println("总大小: " + root.getSize() + " KB");
    }
}

你看，客户端调用 root.display() 时，根本不用关心 root 是文件还是文件夹。它内部会递归调用所有子节点的 display 方法。这就是组合模式的魅力。

两种模式的对比

对比维度 透明组合模式 安全组合模式
接口定义 子节点管理方法在抽象构件中 子节点管理方法只在容器构件中
叶子节点 有 add/remove 方法（空实现或抛异常） 没有 add/remove 方法
客户端调用 无需区分叶子/容器，完全统一 需要类型判断，才能调用子节点管理方法
安全性 运行时可能出错（调用叶子节点的 add） 编译期安全，不会误调用
接口隔离 违反接口隔离原则 符合接口隔离原则
适用场景 树形结构复杂，客户端需要大量统一操作 树形结构简单，客户端调用逻辑清晰

组合模式的知识体系

下面这张图帮你理清组合模式的核心逻辑：

组合模式知识体系 Component 抽象构件 Leaf 叶子构件（文件） Composite 容器构件（文件夹） 包含子节点 Client 依赖抽象接口 客户端通过 Component 接口统一操作 Leaf 和 Composite 透明模式 安全模式

实际项目中的避坑指南

组合模式看起来简单，用起来还是有不少细节要注意。我分享几个实际经验：

  • 递归深度问题：树形结构如果很深，递归调用可能导致栈溢出。我建议在容器节点的 display 方法里用迭代代替递归，或者设置最大深度限制。
  • 共享节点问题：同一个子节点能不能被多个父节点引用？文件系统里不行（一个文件只能在一个文件夹里），但有些场景可以（比如组织架构里一个人可以属于多个部门）。设计时要明确。
  • 缓存问题：如果频繁调用 getSize 这类需要遍历整棵树的方法，建议在容器节点里加缓存。子节点变化时清空缓存。
  • 线程安全：多线程环境下操作树形结构，记得加锁或用 CopyOnWriteArrayList 这类线程安全集合。

一个小技巧：如果你用透明组合模式，可以在抽象构件里把 add/remove 方法声明为 protected，这样外部客户端看不到这些方法，只有子类能调用。既保持了透明性，又减少了误用的可能。

组合模式其实无处不在。除了文件系统，GUI 组件树、组织架构树、XML 文档解析、菜单系统……只要遇到树形层次结构，都可以考虑用组合模式。关键就一句话：让客户端用一致的方式对待单个对象和组合对象。

嗯，今天就聊到这儿。组合模式不难，但用好它需要你对业务场景有清晰的认识。选透明还是安全，没有绝对的对错，看你的具体需求。

← 上一章 📖 返回目录 下一章 →