Java装饰器模式：动态扩展功能不改源码

Java中的装饰器模式是一种通过接口、组合与显式委托来动态增强对象功能的设计技巧，它不依赖语言级的@decorator语法，而是以手写包装类的方式实现日志、权限、缓存等横切关注点的灵活叠加；相比继承和静态工具类，它更符合开闭原则、支持链式嵌套且类型安全，虽需警惕空指针、死循环和接口遗漏等常见陷阱，但性能几乎无损耗；值得注意的是，Spring的@Transactional等看似“装饰”的功能实为运行时代理机制，并非真正意义上的装饰器，二者在调用链、调试方式和this调用行为上存在本质差异——掌握这一模式，能让你在不修改原始代码的前提下，优雅、可控、可复用地扩展系统能力。

Java 里没有 @decorator，得靠接口 + 组合 + 接口实现类包装

Java 本身不支持 Python 那种 @decorator 语法，所谓“装饰器模式”是手动实现的结构设计：用一个类包装另一个类，两者实现同一接口，通过委托调用增强行为。不是语言特性，是编码约定。

常见错误现象：NullPointerException（忘了初始化被包装对象）、死循环调用（delegate.method() 写成 this.method()）、接口方法漏实现（导致编译失败但容易忽略）。

使用场景：日志、权限校验、缓存、事务代理——所有需要在不改原逻辑前提下加横切行为的地方。

• 必须定义统一接口，比如 Service，原始类和装饰器都实现它
• 装饰器构造函数必须接收该接口类型的参数（即被包装对象），不能直接 new 具体实现类
• 每个方法里显式调用 delegate.xxx()，不是自动转发

为什么不能用继承？继承会破坏开闭原则且无法叠加

继承看似简单，但一旦要加第二个功能（比如既加日志又加缓存），就得写 LoggingAndCachingService extends CachingService，再加一个就爆炸。而装饰器可以链式组合：new LoggingDecorator(new CachingDecorator(new RealService()))。

性能影响：每次调用多一层方法跳转，但现代 JVM 基本内联掉，可忽略；兼容性无问题，纯 Java SE 5+ 就行。

容易踩的坑：RealService 如果有非接口方法（比如 getInternalState()），装饰器无法暴露——这是故意的，装饰器只承诺接口契约。

Spring 的 @Transactional 看起来像装饰器，但它其实是代理（Proxy）

Spring 的 @Transactional 不是手写的装饰器类，而是运行时生成代理对象（JDK 动态代理或 CGLIB）。你写的 UserService 类本身没变，Spring 在容器里替换成一个包装了事务逻辑的代理实例。

关键区别：

• 手写装饰器：编译期确定，类型安全，调试直观，但要自己 new 和传参
• Spring 代理：运行期织入，配置驱动，支持 AOP 表达式，但 this.method() 调用会绕过代理（导致事务失效）
• 错误现象：Transaction not active 或日志没打出来，大概率是因为在同一个类里调用了本类另一个 @Transactional 方法

别用静态工具类模拟装饰器——它破坏封装且无法组合

有人写个 LogUtils.wrap(Service s) 返回 Service，看起来简洁，但本质是工厂+匿名内部类，每次都要重复写逻辑，没法复用装饰器状态（比如缓存装饰器要持有一个 Map），更没法嵌套。

正确做法：每个装饰器是独立类，有自己字段、构造逻辑和生命周期。比如 CachingDecorator 持有 ConcurrentHashMap，LoggingDecorator 持有 Logger 实例。

参数差异：装饰器构造函数只接受接口类型，不要塞进具体配置（如缓存大小），那属于装饰器内部策略，应通过 Builder 或构造参数分离。

复杂点在于：多个装饰器嵌套时，执行顺序由 new 的顺序决定，而不是注解顺序——这点和 Spring AOP 完全不同，容易想当然出错。

以上就是《Java装饰器模式：动态扩展功能不改源码》的详细内容，更多关于的资料请关注golang学习网公众号！