What is the Proxy pattern?

Question

Accepted Answer

The **Proxy** pattern provides a **placeholder or surrogate** for another object to control access to it. The proxy has the same interface as the real object but adds behavior — like lazy loading, access control, caching, or logging — before delegating to it.

## What the Proxy pattern does

```text
PROXY → an object that STANDS IN for another, controlling access to it:
  → same interface as the real object (clients use it transparently)
  → adds behavior BEFORE/AROUND delegating to the real object
  → controls WHEN and HOW the real object is accessed
→ "a stand-in that adds control/behavior"
```

## Types of proxies

```text
VIRTUAL proxy → LAZY initialization → create/load the real object only when needed
  (e.g. defer loading a heavy resource until first use)
PROTECTION proxy → ACCESS CONTROL → check permissions before allowing access
CACHING proxy → cache results → return cached data instead of re-fetching/recomputing
REMOTE proxy → represent an object in another location (network/remote calls hidden)
LOGGING/smart proxy → add logging, reference counting, etc. around access
```

## Uses and example

```js
// a caching proxy wraps a service, caching results
class CachingProxy {
  constructor(service) { this.service = service; this.cache = {}; }
  fetch(id) {
    if (!this.cache[id]) this.cache[id] = this.service.fetch(id);  // cache misses
    return this.cache[id];   // serve from cache otherwise
  }
}
```

```text
USES → ORMs (lazy-loading entities), API clients (caching/retry), JS Proxy object,
  access control, virtual proxies for heavy objects, remote service proxies
```

## Why it matters

Understanding the Proxy pattern is valuable because it's a **useful structural pattern** for controlling access to objects, with practical applications, so it's relevant design knowledge.

The Proxy pattern provides a surrogate with the same interface as a real object, adding behavior before delegating to it — controlling when and how the real object is accessed.

Understanding what it does (a stand-in that adds control or behavior while transparently representing the real object) is the core knowledge.

Understanding the **types of proxies** is valuable because each addresses a real need: **virtual proxies** (lazy initialization — deferring the creation or loading of heavy resources until needed, important for performance), **protection proxies** (access control — checking permissions before allowing access), **caching proxies** (caching results to avoid re-fetching or recomputing — a common optimization), **remote proxies** (representing objects in other locations, hiding network calls), and logging/smart proxies.

These cover important cross-cutting concerns (lazy loading, access control, caching, remote access) applied transparently.

Understanding the **uses** — ORMs (lazy-loading entities, a very common real application), API clients (caching and retry), the JavaScript Proxy object, access control, and remote service proxies — clarifies its practical applicability.

The Proxy pattern appears in real frameworks (ORMs lazy-load via proxies, JS has a built-in Proxy) and is the clean way to add access control, caching, or lazy loading transparently around an object.

Since the Proxy pattern is a useful structural pattern for controlling access to objects (lazy loading, access control, caching, remote access) with real applications (ORMs, API clients, JS Proxy), and since understanding what it does and its types is relevant for these common needs, understanding the Proxy pattern is valuable, practically-relevant design knowledge — a useful pattern for controlling object access transparently (lazy loading, caching, access control), appearing in real frameworks like ORMs, and important design knowledge for adding cross-cutting behavior around object access cleanly.