What is the Decorator pattern, and where does the JDK use it (give the canonical example)?
answer
- Same type, holds a reference, delegates, adds behavior
- Composition not subclassing -> avoids class explosion
- java.io: BufferedInputStream wraps InputStream
- Collections.synchronizedList / unmodifiableList wrap a List
- Stackable and substitutable at runtime
basics
~20 sDecorator wraps an object to add behavior without changing its class. It implements the same type as what it wraps and forwards calls to it, adding extra work. The classic JDK example is java.io: BufferedInputStream wraps an InputStream to add buffering.
solid answer
~40 sThe Decorator pattern attaches extra responsibilities to an object dynamically by wrapping it in another object that implements the same interface (or extends the same abstract type). The wrapper holds a reference to the wrapped component, forwards method calls to it, and adds behavior before or after delegating. Because both share a type, a decorator is interchangeable with the thing it decorates, and decorators can be stacked. The textbook JDK example is the java.io stream hierarchy: a FileInputStream provides raw bytes, BufferedInputStream wraps it to add buffering, and you could further wrap that with a DataInputStream to add typed reads. Collections.synchronizedList and Collections.unmodifiableList are also decorators: each returns a List that wraps the original and adds locking or read-only enforcement while delegating the actual storage.
code
java · 11 lines// FileInputStream = concrete component (raw bytes from disk)
// BufferedInputStream = decorator adding a buffer
// DataInputStream = decorator adding typed reads
try (DataInputStream in =
new DataInputStream(
new BufferedInputStream(
new FileInputStream("data.bin")))) {
int id = in.readInt(); // typed read (DataInputStream)
double v = in.readDouble(); // buffered under the hood
}
// All three are InputStreams: each forwards read() to the one it wraps.go deeper
Can state the one-liner: Decorator wraps an object of the same type to add behavior, and name BufferedInputStream over FileInputStream as the example.
Explains the structural rule (same Component type, holds a reference, delegates, adds behavior), why composition beats subclassing, and names both java.io and the Collections wrappers.
Contrasts Decorator with Proxy/Adapter, discusses FilterInputStream as the base decorator, and reasons about substitutability and stacking order.
Frames Decorator against the open/closed principle and interface-driven design, weighs its cost (many small objects, hard-to-debug deep stacks) and notes alternatives like the java.io transparent-decorator critique.
## The problem Decorator solves Suppose you have a basic capability — say, reading bytes from a file — and you want to optionally add features: buffering, decompression, decryption, typed reads, counting bytes. If you tried to express every combination with subclassing, you'd get a class explosion (`BufferedGzipDataFileInputStream`, etc.). Decorator avoids this by letting you **compose** features at runtime: each feature is its own wrapper, and you stack only the ones you need. ## Key terms (defined from scratch) - **Component**: the common type (interface or abstract class) that both the real object and the wrappers share. In java.io this is `InputStream`. - **Concrete component**: the base object that does the real work. e.g. `FileInputStream` (reads bytes from a file). - **Decorator**: an object that *implements the same Component type* and *holds a reference to another Component* (the thing it wraps). It forwards (delegates) calls to the wrapped object and adds behavior before/after. In java.io the base decorator is `FilterInputStream`, and concrete decorators are `BufferedInputStream`, `DataInputStream`, `GZIPInputStream`, etc. - **Delegation / forwarding**: calling the same method on the wrapped object. e.g. `BufferedInputStream.read()` ultimately calls the underlying stream's `read()` to refill its buffer. ## Why "same type" matters Because a decorator *is-a* Component, code that accepts a Component (`void process(InputStream in)`) works identically whether you hand it a raw `FileInputStream` or one wrapped five layers deep. The caller is decoupled from how many features are attached. This is the defining structural rule: a decorator must be **substitutable** for what it wraps. ## The canonical JDK example: java.io streams ```java InputStream in = new BufferedInputStream(new FileInputStream("data.bin")); ``` Here `FileInputStream` is the concrete component (raw bytes). `BufferedInputStream` is a decorator that adds an in-memory buffer so the program makes fewer, larger reads from disk. Both are `InputStream`s, so `in.read()` is polymorphic. You can stack further: wrap the buffered stream in a `DataInputStream` to read `int`/`double`/`UTF` directly, or a `GZIPInputStream` to decompress on the fly. The order of wrapping determines the order features apply. ## Collections decorators The JDK also decorates collections: - `Collections.synchronizedList(list)` returns a `List` that wraps the original and makes each method `synchronized` (thread-safe) while delegating storage to the wrapped list. - `Collections.unmodifiableList(list)` returns a `List` that delegates all reads but throws `UnsupportedOperationException` on any mutation — a read-only decorator. These add behavior (locking, immutability) without changing the original list's class, exactly the Decorator intent. ## What you should remember Decorator = same type + holds a reference + delegates + adds behavior, composed at runtime and stackable. java.io is the interview go-to example; the Collections wrappers are the second.
- Why does Decorator use composition instead of inheritance to add features?Inheritance would require a separate subclass for every feature combination (class explosion) and is fixed at compile time. Composition lets you stack any subset of features at runtime, and each feature is one small, reusable wrapper.
- Is Collections.unmodifiableList a real copy of the list?No. It's a view that wraps the original and delegates reads to it; changes to the underlying list are visible through the wrapper. It only blocks mutating methods, throwing UnsupportedOperationException.
saying these in an interview costs you the question
- Saying Decorator changes the class of the wrapped object (it wraps, never modifies it)
- Confusing it with inheritance — decorators use composition/delegation, not 'extends the concrete class'
- Claiming the decorator does not implement the same interface (then it wouldn't be substitutable)
- Citing Adapter or Proxy as the io example — io is Decorator