Decorator Pattern — Adding Behavior Without Subclassing

The Decorator pattern solves a problem inheritance can't handle cleanly: combining behaviors dynamically. If a DataProcessor has four optional behaviors — logging, encryption, compression, validation — inheritance requires 16 subclasses for every combination. Decorator solves this with composition: each behavior is a wrapper class implementing the same interface that delegates to the wrapped object.

The mechanism is straightforward. A decorator holds a reference to another component with the same interface, adds its behavior before or after calling the wrapped method, and returns the result. Callers never know they're dealing with a decorator. You stack them at runtime in any order — the outermost decorator processes first and delegates inward.

Java I/O streams are the most famous example. BufferedInputStream wraps FileInputStream, and GZIPInputStream can wrap either. Each layer adds exactly one responsibility — buffering, compression, decryption — without modifying the others. This is why Java I/O feels composable, even if the explicit constructor chaining is verbose.

The interview distinction that matters is Decorator vs Proxy. Both wrap an object behind the same interface. Decorator adds behavior transparently — the caller doesn't know logging was added. Proxy controls access — caching, lazy loading, transaction management. Spring's @Transactional is a proxy pattern. The security filter chain is closer to a decorator chain. Same structural mechanics, different intent.