Java代理与装饰模式解析及实现

本文深入剖析了Java中极易混淆的代理模式与装饰模式，明确指出二者虽都采用“包装”手法，但本质迥异：代理模式聚焦于控制访问（如权限校验、远程调用、延迟加载），强调替代性与单一控制点；装饰模式则致力于动态叠加业务功能（如缓冲流、加料咖啡、多层过滤），追求正交增强与运行时灵活组合。文章通过对比UML依赖关系、典型代码实现（静态/动态代理 vs. I/O流与咖啡示例）、Spring AOP机制及常见误用陷阱，厘清核心边界——代理是“替别人做事”，装饰是“帮别人加功能”，并警示开发者：需求初期若错判“管控”与“增强”的本质，后续扩展将导致架构僵化、维护成本陡增。

代理模式和装饰模式在 Java 中都属于结构型设计模式，表面看都用“包装”对象的方式扩展行为，但目的和使用场景截然不同：代理模式重在**控制访问**（比如权限校验、延迟加载、远程调用），装饰模式重在**动态增强功能**（比如给输入流加缓冲、给组件加边框）。

代理模式的核心是“替别人做事”，不是“帮别人加功能”

代理类与被代理类实现同一接口，代理类持有真实对象引用，在调用前后可插入逻辑，但不改变原有接口语义。常见错误是把代理写成“功能叠加器”，结果混淆了职责。

• Proxy 类必须和 RealSubject 实现同一个 Subject 接口，否则无法透明替换
• 静态代理需为每个被代理类手写一个代理类；动态代理（java.lang.reflect.Proxy）则通过 InvocationHandler 统一拦截
• Spring AOP 默认使用 JDK 动态代理（要求目标类实现接口），若无接口则退化为 CGLIB 代理（生成子类），二者代理机制不同，final 类或方法无法被 JDK 代理

public interface Service {
    void execute();
}

public class RealService implements Service {
    public void execute() { System.out.println("real work"); }
}

public class LoggingProxy implements Service {
    private final Service target;
    public LoggingProxy(Service target) { this.target = target; }
    public void execute() {
        System.out.println("before");
        target.execute();
        System.out.println("after");
    }
}

装饰模式的关键是“同类型层层包裹”，支持运行时组合

装饰类与被装饰类实现同一接口，且持有被装饰对象引用，通过构造函数传入——这是它和代理最直观的代码相似点；但装饰模式的意图是让多个装饰器像俄罗斯套娃一样自由堆叠，每层只专注单一职责增强。

• 装饰器必须继承/实现与被装饰对象相同的类型（通常是抽象类或接口），否则无法继续被下一层装饰
• 不能出现“装饰器直接 new 具体实现类”的硬编码，应始终通过构造参数接收被装饰对象
• Java I/O 包是经典案例：BufferedInputStream 装饰 FileInputStream，而它本身又可被 DataInputStream 装饰——顺序影响行为（如先缓冲再读数据，不能反过来）

public interface Coffee {
    String getDescription();
    double getCost();
}

public class SimpleCoffee implements Coffee {
    public String getDescription() { return "Simple coffee"; }
    public double getCost() { return 2.0; }
}

public class Milk implements Coffee {
    private final Coffee coffee;
    public Milk(Coffee coffee) { this.coffee = coffee; }
    public String getDescription() { return coffee.getDescription() + ", milk"; }
    public double getCost() { return coffee.getCost() + 0.5; }
}

别把代理写成装饰，也别把装饰当成代理

一个典型误用：用装饰器做权限检查。这看似可行，但破坏了装饰的“正交增强”原则——权限不是业务功能的自然延伸，而是横切关注点，该由代理或 AOP 承担。反之，若用代理去实现多层日志+压缩+加密，就违背了代理“单一控制点”的定位，代码会迅速僵化。

• 代理适合处理与目标对象无关的通用逻辑（如事务、监控、RPC 序列化），且通常只有一层
• 装饰适合业务相关的、可选的、可叠加的功能扩展（如格式化、过滤、缓存），且层数由运行时决定
• 两者都依赖“接口一致”，但代理强调“替代性”，装饰强调“叠加性”；从 UML 类图看，代理是代理类→被代理类的单向依赖，装饰是装饰类→组件接口→被装饰类的环形依赖

真正难的是在需求模糊时判断：这个“包装”是为了管控访问，还是为了丰富能力？一旦方向错了，后续每加一层都会让维护成本翻倍。

以上就是本文的全部内容了，是否有顺利帮助你解决问题？若是能给你带来学习上的帮助，请大家多多支持golang学习网！更多关于文章的相关知识，也可关注golang学习网公众号。