Java装饰者模式：动态扩展功能解析

装饰者模式是一种通过组合而非继承来动态扩展对象功能的灵活设计思想，它让开发者能在运行时像叠纸杯一样自由组合多种增强行为（如日志、鉴权、缓冲、解压），避免了继承带来的僵化与爆炸式子类增长；文章以JDK中InputStream系列装饰器为经典范例，深入剖析了正确实现的关键——接口统一、委托透传、资源复用，并直击新手常踩的三大坑：错误继承引发ClassCastException、遗漏equals/hashCode导致缓存失效、以及空指针和资源重复创建等隐蔽性极强的线上故障根源，揭示真正考验架构功力的，从来不是代码能否跑通，而是责任边界、生命周期与异常处理这些“看不见却致命”的设计细节。

装饰者模式不是“给类加个注解”，而是用组合代替继承，在运行时动态套一层新行为。

为什么不能直接继承？

继承写死在编译期，一个子类只能固定扩展一种能力；而装饰者允许你像叠纸杯一样，new LoggingDecorator(new AuthDecorator(new ServiceImpl()))，顺序、数量、组合方式全由调用方决定。

常见错误现象：ClassCastException —— 有人试图让装饰器继承被装饰类，又把它强转回原类型，结果父类引用指向子类实例，但装饰器根本没重写所有方法，一调就崩。

• 装饰器必须和被装饰类实现同一接口（比如 Service），而不是继承它
• 装饰器内部持有一个该接口的引用（通常是构造函数传入），所有方法默认委托给它
• 只在需要增强的地方重写，其余保持透传

InputStream 是最典型的装饰者现实案例

JDK 里的 BufferedInputStream、DataInputStream、GZIPInputStream 全是装饰器：它们都接收一个 InputStream，自己也返回 InputStream，调用方完全感知不到底层是谁。

使用场景：读文件时既要缓冲、又要解压、还要按行解析——不用改 FileInputStream 一行代码，直接套三层：

new BufferedReader(
  new InputStreamReader(
    new GZIPInputStream(
      new FileInputStream("data.gz"))))

注意参数差异：GZIPInputStream 构造函数只接受 InputStream，不接受 File 或路径；BufferedReader 接受的是 Reader，所以中间必须用 InputStreamReader 转码——漏掉任何一层，编译直接报错。

自己写装饰器时最容易漏掉的三件事

很多人写了构造函数、重写了几个方法，就以为完事了，结果上线后出诡异 bug。

• 忘记重写 equals() 和 hashCode() —— 如果装饰器参与缓存或集合操作，两个功能相同但包装层级不同的对象会判为不等
• 装饰器里调用被装饰对象的方法时，没做空判断，delegate.doSomething() 中 delegate 是 null 就直接 NullPointerException
• 性能陷阱：有些装饰器会在每次调用时新建资源（比如每次 log() 都开一个 FileWriter），应该把资源提到构造期初始化并复用

真正难的不是写出来，是想清楚哪一层该做什么、谁负责释放资源、异常怎么透传——这些不会体现在 UML 图上，但线上挂了第一个找的就是这儿。

今天关于《Java装饰者模式：动态扩展功能解析》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！