How does the Proxy pattern differ from the Decorator pattern, given that both wrap an object behind the same interface?

## Why the confusion exists Both patterns produce the same picture: ``` Client -> Subject (interface) ^ ^ | | RealSubject Wrapper --has-a--> Subject ``` The wrapper implements the interface it wraps, so from a class diagram Proxy, Decorator, and even the pass-through part of Adapter/Chain-of-Responsibility can look identical. The Gang of Four classify patterns by **intent**, not shape, so you must reason about *why* the indirection exists. ## Definitions, restated precisely - **Proxy** — "Provide a surrogate or placeholder for another object to **control access** to it." The proxy stands *in place of* the subject. It may decide the subject is never touched at all (denied by a protection proxy, served from cache by a caching proxy, not yet created by a virtual proxy). - **Decorator** — "Attach **additional responsibilities** to an object dynamically." The decorator *augments* the subject. The underlying call is the point; the decorator adds something before, after, or around it. ## The discriminators | Dimension | Proxy | Decorator | |---|---|---| | **Intent** | Control access — whether/when/where | Add behavior — what else happens | | **Does the call reach the target?** | Possibly not (denied, cached, not yet created, unreachable) | Yes, essentially always | | **Who supplies the target?** | The proxy itself often creates or locates it (constructs lazily, resolves a remote endpoint, looks it up in a registry) | The client injects an already-existing instance | | **Lifecycle ownership** | Frequently owns it | Never owns it | | **Composition** | Usually one, fixed at design time | Explicitly stackable; order is meaningful | | **Client awareness** | Client typically has no idea; obtains the proxy from a factory/container | Client deliberately assembles the chain | | **Interface knowledge** | Often knows the *concrete* subject type (to instantiate it) | Knows only the *interface* | ## Worked examples **Proxy:** - `LazyImage` that reads the file on first `render()` — the file may never be read. - `SecureAccountService` that throws unless the caller has role `TELLER` — the call may never reach the account service. - A gRPC client stub — the "object" is on another machine. - An ORM lazy collection — iterating triggers the SELECT; not iterating means no SELECT. **Decorator:** - `BufferedStream(GZipStream(FileStream(...)))` — every write goes all the way down; each layer transforms it. - `PricedWithTax(PricedWithDiscount(basePrice))` — each layer adjusts the number the inner one returned. - A UI `ScrollableWindow(BorderedWindow(window))` — both add chrome around a window that certainly still draws. ## Grey areas (and how to resolve them) - **Caching wrapper** — Proxy. It exists to avoid reaching the subject. (Some authors call it a decorator because it "adds caching"; the GoF-consistent read is Proxy, since access is what's controlled.) - **Logging wrapper** — Decorator by intent (adds an incidental responsibility, always calls through). An *auditing* wrapper that can also block is a protection proxy. - **Retry wrapper** — Proxy-ish (a smart reference around a remote subject) since it governs how/whether the subject is reached; it usually pairs with a remote proxy. - **Rate limiter / circuit breaker** — Proxy: their whole job is to sometimes *not* forward. ## Why the distinction matters practically 1. **Reviewer vocabulary** — naming the class `OrderServiceProxy` vs `LoggingOrderService` tells the next reader whether skipping the delegate is legal. 2. **Testing** — a decorator's tests assert the delegate was called and the result transformed; a proxy's tests must include the *not forwarded* paths (denied, cached, lazy). 3. **Design pressure** — decorators are expected to compose in any order; proxies aren't, so stacking five proxies usually signals a missing abstraction (or a job for an interceptor pipeline). 4. **Substitutability** — both must satisfy the Liskov Substitution Principle for the shared interface, but a protection proxy that throws where the subject wouldn't is a real LSP tension you must document in the contract (e.g. the interface declares an authorization failure). ## Nearby cousins, for completeness - **Adapter** — changes the interface (Proxy keeps it identical). - **Facade** — one simplified entry point over a *set* of objects (Proxy mirrors one object). - **Chain of Responsibility** — a wrapper chain where a link may handle and stop, but links needn't share the handled object's interface and the chain, not access control, is the point.