装饰器模式（一文讲透）

💡一则或许对你有用的小广告

欢迎加入小哈的星球 ，你将获得：专属的项目实战 / 1v1 提问 / Java 学习路线 / 学习打卡 / 每月赠书 / 社群讨论

• 新项目:《从零手撸：仿小红书（微服务架构）》 正在持续爆肝中，基于 Spring Cloud Alibaba + Spring Boot 3.x + JDK 17...，点击查看项目介绍 ;
• 《从零手撸：前后端分离博客项目（全栈开发）》 2 期已完结，演示链接： http://116.62.199.48/ ;

截止目前， 星球 内专栏累计输出 82w+ 字，讲解图 3441+ 张，还在持续爆肝中.. 后续还会上新更多项目，目标是将 Java 领域典型的项目都整一波，如秒杀系统, 在线商城, IM 即时通讯，权限管理，Spring Cloud Alibaba 微服务等等，已有 2900+ 小伙伴加入学习 ，欢迎点击围观

引言：从披萨配料说起

在软件开发中，我们常常需要给对象动态添加功能。就像制作披萨时，可以根据需求添加芝士、火腿、蘑菇等配料，装饰器模式提供了一种灵活且可扩展的方式，让开发者能够以非侵入的方式增强对象的行为。这种模式不仅避免了继承的僵化性，还能让代码结构更清晰。接下来，我们将通过生活化的比喻和实际代码案例，深入理解装饰器模式的核心思想与应用场景。

一、装饰器模式的定义与核心思想

1.1 模式定义

装饰器模式（Decorator Pattern）属于结构型设计模式，其核心是通过组合而非继承来动态扩展对象的功能。它允许在运行时为对象"包裹"一层包装，每层包装（即装饰器）可以添加新的行为，同时保持原有接口的兼容性。

1.2 核心概念解析

• 组件（Component）：定义对象的公共接口，所有具体组件和装饰器都继承自它。
• 具体组件（Concrete Component）：实现基础功能的实体对象。
• 装饰器（Decorator）：维护一个对Component的引用，并定义一个与Component一致的接口。
• 具体装饰器（Concrete Decorator）：在运行时给组件动态添加职责。

形象比喻：
想象一个标准的披萨店菜单，所有披萨都继承自"披萨"基类。具体组件可以是"基础玛格丽特披萨"，而装饰器则像配料选项：每个装饰器（如"加芝士装饰器"）都包含一个披萨实例，并在原有基础上叠加新功能（如增加芝士层）。最终客户可以选择任意组合，而所有披萨仍然保持相同的点餐接口。

二、装饰器模式 vs 继承模式

2.1 继承模式的局限性

通过继承扩展功能时，需要预先定义所有可能的组合，这会导致：

• 类爆炸问题：若4个基础类与3种扩展功能组合，需创建12个子类
• 灵活性不足：无法在运行时动态选择功能组合

2.2 装饰器模式的优势对比

2.3 实际场景选择建议

当需要满足以下条件时，优先考虑装饰器模式：

1. 需要动态、透明地为对象添加/移除功能
2. 功能扩展需要保持原有接口兼容性
3. 避免因继承导致的类爆炸问题

三、装饰器模式的实现步骤

3.1 实现流程图示

抽象组件接口
  │
  ├─ 具体组件（基础实现）
  │
  ├─ 装饰器基类（持有组件引用）
      │
      ├─ 具体装饰器A（添加功能X）
      │
      └─ 具体装饰器B（添加功能Y）

3.2 实现步骤详解

1. 定义组件接口：声明所有对象共有的基本操作
2. 创建具体组件：实现核心业务逻辑的基础类
3. 构建装饰器基类：包含对组件的引用，并继承组件接口
4. 开发具体装饰器：在装饰器基类基础上实现新增功能
5. 动态组合装饰器：通过客户端代码按需叠加装饰器层

四、经典案例：网络请求装饰器

4.1 场景描述

我们需要构建一个HTTP客户端，支持以下功能：

• 基础请求功能
• 日志记录
• 认证处理
• 超时重试机制

4.2 代码实现（Java示例）

// 组件接口：定义基础请求行为
interface HttpClient {
    String sendRequest(String url);
}

// 具体组件：基础HTTP客户端
class SimpleHttpClient implements HttpClient {
    @Override
    public String sendRequest(String url) {
        // 省略HTTP请求实现细节
        return "Response from " + url;
    }
}

// 装饰器基类：持有组件引用
abstract class HttpClientDecorator implements HttpClient {
    protected HttpClient decoratedClient;

    public HttpClientDecorator(HttpClient client) {
        this.decoratedClient = client;
    }
}

// 具体装饰器：添加日志功能
class LoggingDecorator extends HttpClientDecorator {
    public LoggingDecorator(HttpClient client) {
        super(client);
    }

    @Override
    public String sendRequest(String url) {
        System.out.println("Starting request to " + url);
        String result = decoratedClient.sendRequest(url);
        System.out.println("Request completed");
        return result;
    }
}

// 其他装饰器：认证处理
class AuthDecorator extends HttpClientDecorator {
    private String token;

    public AuthDecorator(HttpClient client, String token) {
        super(client);
        this.token = token;
    }

    @Override
    public String sendRequest(String url) {
        // 添加认证头
        System.out.println("Adding auth token: " + token);
        return decoratedClient.sendRequest(url);
    }
}

// 客户端使用示例
public class Client {
    public static void main(String[] args) {
        HttpClient baseClient = new SimpleHttpClient();
        HttpClient clientWithLogs = new LoggingDecorator(baseClient);
        HttpClient fullyDecorated = new AuthDecorator(clientWithLogs, "xyz123");
        
        String response = fullyDecorated.sendRequest("https://api.example.com");
        // 输出包含日志和认证信息的完整请求
    }
}

4.3 模式优势体现

1. 动态组合：客户端可自由选择装饰器组合，如仅使用日志或同时使用日志+认证
2. 开闭原则：新增重试机制时只需创建RetryDecorator，无需修改现有代码
3. 解耦设计：认证逻辑与基础请求实现完全分离，便于独立维护

五、进阶应用：装饰器模式的变体与扩展

5.1 多层装饰器嵌套

通过链式调用可以创建任意深度的装饰器组合：

HttpClient client = new RetryDecorator(
    new LoggingDecorator(
        new AuthDecorator(
            new SimpleHttpClient(), "token"
        )
    ), 3 // 重试次数
);

5.2 装饰器与策略模式结合

在装饰器中使用策略模式选择不同实现：

// 抽象装饰器持有策略对象
class CompressionDecorator extends HttpClientDecorator {
    private CompressionStrategy strategy;

    public CompressionDecorator(HttpClient client, CompressionStrategy strategy) {
        super(client);
        this.strategy = strategy;
    }

    @Override
    public String sendRequest(String url) {
        String compressedData = strategy.compress(requestData);
        return decoratedClient.send(compressedData);
    }
}

5.3 装饰器的性能考量

• 调用链深度：过多装饰器可能影响性能，建议通过工厂模式管理组合
• 状态共享：装饰器之间可通过共享上下文对象传递状态信息

六、常见问题与解决方案

6.1 问题1：装饰器如何避免无限递归？

在装饰器方法中，必须显式调用decoratedClient的方法，而非直接使用super：

// 正确做法
return decoratedClient.sendRequest(url);

// 错误示范（导致递归）
return super.sendRequest(url); // 若装饰器继承自抽象类，可能导致无限调用

6.2 问题2：装饰器如何修改返回值？

在装饰器方法中：

// 修改响应内容
String original = decoratedClient.sendRequest(url);
return original.replace("old", "new");

6.3 问题3：如何序列化装饰器对象？

当需要序列化时，确保装饰器类实现Serializable接口，并正确处理内部引用关系。

七、适用场景与最佳实践

7.1 典型应用场景

• UI组件增强：给按钮添加弹窗、进度条等附加行为
• 日志与监控：为方法调用添加性能统计、日志记录
• 网络请求：实现认证、重试、压缩等通用功能
• 数据库访问：添加事务管理、缓存机制

7.2 设计建议

1. 保持接口一致性：确保装饰器与组件实现相同接口
2. 避免过度装饰：超过5层的装饰可能暗示需要重构
3. 使用工厂模式：通过工厂创建装饰器组合，提升可维护性

结论：动态扩展的艺术

装饰器模式通过"组合优先于继承"的设计哲学，为功能扩展提供了优雅的解决方案。它像乐高积木般允许开发者自由拼接功能模块，同时保持系统的灵活性和可维护性。掌握这一模式后，我们可以在不破坏原有代码结构的前提下，应对复杂多变的需求变化。下次当你需要给系统添加新功能时，不妨考虑用装饰器模式来构建可扩展的解决方案。

提示：实际开发中，Python的装饰器语法（@decorator）与该模式有异曲同工之妙，但需要区分语言特性与设计模式的本质区别。