What is the Proxy design pattern, and what does it look like in Java?

## The problem Sometimes you don't want callers to talk to an object directly. Maybe the object is expensive to create and you want to defer that until it's actually used; maybe you need a security check before any method runs; maybe the object lives on another machine; maybe you want to log or cache every call. In all these cases you want something that *looks exactly like* the real object but sits in front of it and **controls access** to it. ## The pattern The **Proxy pattern** introduces a *surrogate* (the proxy) that implements the **same interface** as the *real subject*. Because they share an interface, a caller holding the interface type cannot tell whether it has the proxy or the real thing — the proxy is **transparent**. Every method call lands on the proxy, which can do work *before* and *after* forwarding (delegating) the call to the real subject. Three roles: - **Subject** — the shared interface (e.g. `Image`). - **RealSubject** — the actual implementation (e.g. `HighResImage`). - **Proxy** — implements `Subject`, holds a reference to the `RealSubject` (or creates it lazily), and forwards calls. ## Kinds of proxy - **Virtual proxy** — delays creating an expensive real object until a method is first called (lazy loading). Example: don't load a huge image from disk until `display()` is called. - **Protection proxy** — checks permissions before delegating; throws or returns early if the caller isn't allowed. - **Remote proxy** — local stand-in for an object that actually lives in another JVM/process/machine; the proxy marshals the call across the network (the classic example is Java RMI stubs). - **Smart proxy / smart reference** — adds bookkeeping: logging, caching, reference counting, lazy locking. ## Two ways to build it in Java **1. Static (hand-written) proxy.** You write a class that implements the interface, holds the target, and forwards each method explicitly. Simple and explicit, but you must write one forwarding method per interface method, and a new proxy class per interface. ```java class LoggingService implements Service { private final Service target; LoggingService(Service target) { this.target = target; } public String fetch(int id) { System.out.println("calling fetch(" + id + ")"); return target.fetch(id); } } ``` **2. Dynamic proxy.** `java.lang.reflect.Proxy.newProxyInstance(...)` *generates* a proxy class at runtime that implements a given set of interfaces. Every method call on it is routed to a single `InvocationHandler.invoke(proxy, method, args)` method, where you write the cross-cutting logic once and delegate via `method.invoke(target, args)`. This avoids hand-writing a forwarder per method and is the basis of most framework interception (Spring AOP's JDK-proxy mode, mocking libraries, transaction/security interceptors). Its one constraint: JDK dynamic proxies can only proxy **interfaces**, not concrete classes (libraries like CGLIB/ByteBuddy subclass instead, to proxy classes). ## Proxy vs Decorator Both wrap an object that shares the wrapped type, so they look structurally identical. The difference is **intent**: a **Decorator adds new behavior/responsibilities** to an object (and you typically stack several), while a **Proxy controls access** to an object (existence, permissions, location) and usually wraps exactly one target whose lifecycle it may even own. A decorator's client knowingly composes behaviors; a proxy is meant to be invisible. ## Why it matters Proxies are the mechanism behind huge parts of the Java ecosystem: Spring's declarative `@Transactional`/`@Async`/`@Cacheable`/`@PreAuthorize`, Hibernate lazy-loaded entity associations, RMI stubs, and most mock objects are all proxies intercepting calls and adding behavior around a real (or fake) target.