Implement the Decorator pattern. How does wrapping add behavior without modifying the original, and how does it relate to HOCs?
Choosing composition (wrap-and-delegate) over subclassing to layer behavior, and recognising the pattern in function wrappers, HOCs, and TS decorators.
Decorator attaches new responsibilities to an object or function by WRAPPING it in another object/function with the same interface, delegating to the original and adding behavior around it. The signal: you want to add a cross-cutting concern — logging, caching, timing, retry, authorization — to something without editing its source and without a subclass explosion (if every combination of features needs its own subclass, you get 2^n classes; decorators let you STACK features at runtime instead). Because each decorator preserves the wrapped thing's interface, decorators compose — you can wrap a wrap a wrap, and the order is meaningful. In JavaScript the most common form is the function decorator: a higher-order function that takes a function and returns a new function calling through to it with extra behavior (this is exactly how `once` (js-32), `memoize` (js-10), `debounce` (js-4), and `throttle` (js-5) work — they're all decorators). It shows up structurally across the ecosystem: React Higher-Order Components (`withAuth(Component)`) wrap a component to inject props/behavior; Express middleware wraps request handling; TypeScript/Angular `@decorators` are the syntactic form applied to classes and members. Contrast with inheritance: subclassing fixes behavior at author time and is static; decoration composes behavior at runtime and stays flexible. The trade-off is more small wrappers and indirection in stack traces — worth it for orthogonal concerns you want to mix and match.
Layering cross-cutting behavior (logging, caching, retry, auth) onto functions or components without editing them — function wrappers, React HOCs, middleware, TS decorators.
O(1) overhead per wrap layer.