What practical problems appear once a system leans heavily on Decorator — around object identity, type checks, and calls an object makes to itself?

## 1. Identity is not preserved A decorator is a genuinely different object. Consequences: - **Reference comparison fails.** Code doing `if (store == expectedStore)` breaks after wrapping. - **Identity-keyed structures split.** Registering the raw object and later looking up the wrapper (or vice versa) yields a miss. - **Equality is a trap.** Making the wrapper `equals` the wrappee cannot be done symmetrically or transitively: the wrappee has no knowledge of the wrapper, so `wrapper.equals(inner)` might be true while `inner.equals(wrapper)` is false — a broken equality contract that corrupts hash-based collections. The safe rule: decorate behavior, never identity. If callers must compare, give them a stable business key on the interface instead of relying on object identity. - **Serialization and caching by object graph** likewise see the wrapper's shape, not the original's. ## 2. Type interrogation and casting Once wrapped, the runtime type is the decorator's. Anything that reaches past the interface breaks: - `instanceof ConcreteImpl` / `as ConcreteImpl` casts. - Reading class-level annotations or attributes from the object's class. - Reflective inspection expecting the real class's fields or method annotations. - Framework registries keyed by concrete class. Mitigations: keep clients depending strictly on the interface; if unavoidable, expose an explicit `unwrap()`/`getTarget()` on a marker interface so callers can descend deliberately rather than by accident — but treat every use as a design smell, because it re-couples clients to the implementation the pattern was meant to hide. ## 3. The self-invocation (self-reference) problem This is the subtlest and most important one. Decoration works by interposing on calls that arrive *from outside*. If the inner object's method calls another of *its own* methods directly, that call is dispatched on the inner object's own reference — the wrapper never sees it. ``` class RealStore implements Store { void writeAll(items) { for (i in items) this.write(i) } // internal call void write(item) { ...disk... } } Store s = new AuditingStore(new RealStore()) s.writeAll(items) // audited ONCE, for writeAll only // the individual write() calls are NOT audited ``` The wrapped object has no reference to its wrapper, so it cannot route self-calls outward. This is exactly why framework annotations implemented by generated proxies (declarative transactions, caching, security, async) famously "do not work on internal method calls". Workarounds, roughly in order of preference: - **Split the object** so the composite operation and the primitive operation live in different objects; the outer one then calls the inner one through the interface, and decoration applies. - **Keep decorated methods free of self-calls** — treat internal helpers as private so they were never part of the decorated contract in the first place. - **Inject a self-reference** (the object receives the fully-wrapped instance and routes outward through it), which works but creates a circular dependency and is easy to get wrong. - **Move the concern inside** the class when interception genuinely cannot be made to work. ## 4. Interface evolution Every method added to the component interface must be implemented by every decorator. Two mitigations, each with a downside: - An **abstract base decorator** that forwards all methods: new methods only need a pass-through added once. But new methods will silently be *undecorated* in every concrete decorator — a caching wrapper that never learned about the new `readBatch` method silently bypasses caching. - **Default/interface methods** delegating to existing ones: convenient, but a default implemented in terms of other methods may double-count in decorators that override both. Narrow interfaces (Interface Segregation) keep decorators cheap; a fat interface makes each wrapper a wall of boilerplate and discourages the pattern entirely. ## 5. Operational and cognitive costs - **Stack depth and traces.** Ten wrappers add ten frames to every trace and make "where did this actually happen" harder to read; give wrappers descriptive class names. - **Invisible configuration.** Reading a class tells you nothing about which wrappers are active; the truth lives in the wiring code. Keep composition in one place, and consider logging the composed stack at startup. - **Lifecycle leaks.** `close()`, `flush()`, `shutdown()` must be forwarded or resources leak; a wrapper that forgets one method of a lifecycle contract creates a hard-to-find bug. - **Thread safety and state.** A wrapper holding mutable state (a cache, counters) must be as thread-safe as the contract requires; and wrapping a stateful object twice from different code paths can produce two independent caches over the same target. - **Exception and contract fidelity.** A wrapper must not narrow or widen the contract: swallowing exceptions, changing null semantics, or altering ordering breaks substitutability (Liskov) for callers who cannot see the wrapper. - **Double wrapping.** Without care, wiring can apply the same decorator twice (metrics counted twice, retries multiplied: 3 retries inside 3 retries = 9 attempts). Make composition idempotent or centralized.