When would you deliberately NOT use hand-written Decorator wrappers for cross-cutting behavior, and what would you use instead?

## Where Decorator earns its keep Optional, orthogonal capabilities attached to one focused abstraction, chosen at wiring time: retry/cache/metrics around a specific gateway, buffering/compression around a stream, read-only or thread-safe views of a collection. Small interface, few wrappers, explicit composition — the pattern is close to free. ## Signals to choose something else ### 1. The concern is horizontal, not vertical Logging, tracing, authentication, and metrics usually apply to *every* inbound request, not to one interface. Writing one decorator per interface produces N nearly identical classes. *Alternatives:* - **Middleware / interceptor pipeline** — a single ordered chain of same-signature handlers around a generic request/response, configured once at the edge. Structurally decoration generalized to one uniform signature. - **Aspect-oriented programming / declarative annotations** — pointcuts or annotations that a framework weaves in (usually by generating proxies). Very little code, but implicit. - **Generated dynamic proxies** — one reflective handler applied to any interface, avoiding hand-written pass-throughs at the price of reflection cost and weaker static typing. - **Platform-level solutions** — for network concerns, a sidecar/service mesh or gateway handles retries, timeouts, mTLS, and tracing outside the process entirely, uniformly for all languages. ### 2. There is exactly one variation, forever If logging is always on and never optional, a decorator adds an indirection with no combinatorial payoff. Prefer straight code, or a boolean/feature flag inside the implementation. Patterns are a response to variability; no variability, no pattern. ### 3. The interface is fat or unstable Every decorator must implement every method. A wide or frequently changing interface turns wrappers into churn magnets. Split the interface by role first; if you cannot (third-party contract), a generated proxy or an adapter to a narrower internal interface is kinder. ### 4. Clients depend on concrete types, or self-calls matter If callers cast to the implementation, read its annotations, or compare identity, wrapping breaks them. If the behavior must apply to calls a class makes to *itself*, no external wrapper can intercept it — the logic belongs inside, or the class must be split. ### 5. Behavior needs to change *inside* the algorithm Decorator layers around the boundary. Varying a step *within* an operation is Strategy or Template Method; contorting decorators to reach inside leads to leaked state and out-parameters. ### 6. Performance-critical inner loops Each layer is an extra virtual call and possibly an allocation. Almost always irrelevant, but in tight numeric loops or per-element stream processing, collapse the layers. ### 7. State that must be shared across layers Wrappers communicate only through the interface's parameters and return values. If layers need shared context (trace ids, deadlines, tenant), you need an explicit context object threaded through the contract or ambient context support — otherwise wrappers start reaching for globals. ## Governance concerns at scale - **Ordering is a system property.** Once dozens of services compose retry/breaker/cache/auth wrappers by hand, orders diverge and behavior differs per service. Centralize composition in a shared factory with a declared order, or move the concerns into a pipeline/mesh where order is configured once. - **Explicit vs implicit is the real trade.** Decorators are visible in wiring, steppable in a debugger, trivially unit-testable in isolation, and honest about their cost. Annotations/aspects are terse but hide interception, surprise developers with self-call gaps, and make ordering a matter of framework-specific precedence rules. Many teams settle on: implicit framework interception for truly universal concerns, explicit decorators for domain-specific, behavior-changing ones such as caching or fallbacks whose semantics deserve to be read in code. - **Discoverability.** Log or expose the composed stack at startup so operators can see which layers are active in each environment. - **Testing.** Test each wrapper against a stub of the interface, and add integration tests for the composed stack's cross-layer properties (a cache hit produces no backend call; a tripped breaker short-circuits retries).