一、从咖啡店理解装饰模式（现实场景）

想象你在咖啡店点单：
o 基础款：美式咖啡（18元）
o 可选配料：加奶（+3元）、加糖（+1元）、加巧克力（+5元）

如果使用传统继承方式，会出现"美式加奶"、"拿铁加糖"、"摩卡加巧克力加奶"等数十种组合，导致类爆炸。这正是装饰模式要解决的问题——动态叠加功能而不产生冗余子类。

二、模式核心思想

1. 四大核心角色

2. UML类图

三、代码实现（咖啡店案例）

1. 组件接口

public interface Coffee {
    String getDescription();  // 获取描述
    double cost();            // 计算价格
}

2. 具体组件

public class Americano implements Coffee {
    @Override
    public String getDescription() {
        return"美式咖啡";
    }

    @Override
    public double cost() {
        return18.0;
    }
}

3. 抽象装饰器

public abstract class CondimentDecorator implements Coffee {
    protected Coffee coffee;  // 关键：持有组件对象
    
    public CondimentDecorator(Coffee coffee) {
        this.coffee = coffee;
    }

    @Override
    public String getDescription() {
        return coffee.getDescription();
    }

    @Override
    publicdoublecost() {
        return coffee.cost();
    }
}

4. 具体装饰器

public class Milk extends CondimentDecorator {
    publicMilk(Coffee coffee) {
        super(coffee);
    }

    @Override
    public String getDescription() {
        return coffee.getDescription() + "+牛奶";
    }

    @Override
    publicdoublecost() {
        return coffee.cost() + 3.0;
    }
}

public class Sugar extends CondimentDecorator {
    public Sugar(Coffee coffee) {
        super(coffee);
    }

    @Override
    public String getDescription() {
        return coffee.getDescription() + "+糖";
    }

    @Override
    public double cost() {
        return coffee.cost() + 1.0;
    }
}

5. 客户端使用

public class CoffeeShop {
    public static void main(String[] args) {
        // 基础款美式
        Coffee coffee=new Americano();
        System.out.println(coffee.getDescription() + " 价格：" + coffee.cost());

        // 加奶
        coffee = new Milk(coffee);
        System.out.println(coffee.getDescription() + " 价格：" + coffee.cost());

        // 再加糖
        coffee = new Sugar(coffee);
        System.out.println(coffee.getDescription() + " 价格：" + coffee.cost());
    }
}

输出结果：

美式咖啡 价格：18.0
美式咖啡+牛奶 价格：21.0
美式咖啡+牛奶+糖 价格：22.0

四、六大经典应用场景

1. Java I/O流体系

// 文件读取 → 缓冲装饰 → 数据转换装饰
InputStream in = new DataInputStream(
                  new BufferedInputStream(
                    new FileInputStream("data.txt")));

o FileInputStream是具体组件
o BufferedInputStream是装饰器

2. Spring事务管理

@Transactional
public void transferMoney() {
    // 事务操作（通过装饰器添加事务控制）
}

Spring通过AOP动态添加事务管理功能

3. GUI组件扩展

为按钮添加边框、阴影等视觉效果，无需修改按钮基类

4. 日志系统增强

在核心业务逻辑外包裹日志记录功能：

public class LogDecorator extends ServiceDecorator {
    public void execute() {
        log.info("开始执行");
        super.execute();
        log.info("执行完成");
    }
}

5. 权限校验

public class AuthDecorator extends APIDecorator {
    public void request() {
        if(checkAuth()) {
            super.request();
        }
    }
}

6. 数据加密传输

// 基础数据流 → 加密装饰 → 压缩装饰
DataStream stream = new CompressionDecorator(
                     new EncryptionDecorator(
                       new BasicStream()));

网页的加密/压缩装饰器案例正是典型应用

五、模式优势与局限

优势分析

1. 1. 动态扩展：运行时添加功能（如咖啡加配料）
2. 2. 避免继承爆炸：替代多层继承（减少90%类数量）
3. 3. 符合开闭原则：扩展开放，修改关闭
4. 4. 灵活组合：不同装饰器自由叠加（牛奶+糖+巧克力）

使用局限

1. 1. 小对象激增：过度使用会产生大量装饰器对象
2. 2. 调试困难：多层嵌套时调用链复杂（需注意装饰顺序）
3. 3. 设计复杂度：需要正确设计组件接口

六、与相似模式对比

七、最佳实践指南

1. 实现技巧

o 链式调用：返回this实现方法链（参考网页的咖啡案例）
o 接口设计：组件接口要足够抽象（如Coffee接口）
o 默认实现：装饰器基类提供空实现（如CondimentDecorator）

2. 性能优化

o 避免深层嵌套：装饰层级不超过3层
o 对象复用：对常用组合提供工厂方法
o 延迟加载：在装饰器初始化时不立即加载资源

3. 常见误区

o 装饰器包含业务逻辑：应保持装饰器的单一职责
o 与组件强耦合：装饰器应只依赖接口而非具体类
o 替代所有继承：简单扩展仍可用继承（如固定套餐）

八、从原理到框架

1. Spring中的装饰模式

Spring通过BeanPostProcessor实现Bean的装饰：

public class CacheDecorator implements BeanPostProcessor {
    public Object postProcessBeforeInitialization(Object bean, String name) {
        return new CachedBean(bean); // 添加缓存装饰
    }
}

2. MyBatis的TypeHandler

通过装饰器处理不同类型的数据转换：

public class EncryptedTypeHandler extends BaseTypeHandler {
    private TypeHandler handler;
    
    publicEncryptedTypeHandler(TypeHandler handler) {
        this.handler = handler;
    }
    
    publicvoidsetParameter(PreparedStatement ps, int i, String param) {
        ps.setString(i, encrypt(param)); // 添加加密装饰
    }
}

九、总结与展望

装饰模式如同编程中的俄罗斯套娃，通过层层包裹实现功能扩展。其核心价值体现在：

1. 1. 动态性：比继承更灵活的功能扩展方式
2. 2. 正交性：不同维度的功能独立变化
3. 3. 可维护性：避免修改现有稳定代码

在微服务架构趋势下，装饰模式演进为：
o 服务网格中的边车模式（Sidecar）
o 云原生环境的功能插件机制
o 智能合约的扩展模块

掌握这种"动态穿衣"的编程思维，能让你的代码像乐高积木一样灵活组合，轻松应对各种需求变化。