This lesson follows Flyweight and closes the structural patterns.

Proxy stands in for another object and controls access to it through the same contract. The client can use the proxy where it expects the service. That convenience adds hidden work and lifecycle decisions.

Delay an object that is rarely used

An editor can preview a document. Its renderer has expensive font initialization. Most sessions never open preview. Creating the renderer at startup charges every session for a feature only some use.

interface Preview { render(document: string): string }
class DocumentRenderer implements Preview {
  constructor() { console.log("Initialize renderer fonts"); }
  render(document: string) { return "Preview: " + document; }
}
class LazyPreview implements Preview {
  private service: Preview | undefined;
  constructor(private create: () => Preview) {}
  render(document: string): string {
    this.service ??= this.create();
    return this.service.render(document);
  }
}

const preview: Preview = new LazyPreview(() => new DocumentRenderer());
// No renderer yet.
preview.render("Draft A"); // initialize, then render
preview.render("Draft B"); // reuse, then render

Match the proxy to the access problem

Other proxies log calls or manage references to an expensive resource. The common idea is a substitute that mediates access. The mechanism depends on the problem.

Map the roles

Role	In this example	Job
Service interface	Preview	Declares the interface of the service. The proxy must follow it to pass as the service.
Service	DocumentRenderer	A class that provides useful business logic
Proxy	LazyPreview	Holds a reference to the service. Does its own job, such as lazy initialization, logging, access control, or caching, then passes the request to the service. Usually manages the service's whole life cycle.
Client	the editor	Works with services and proxies through the same interface, so a proxy fits anywhere a service is expected

Reach for it when access to an object needs a gatekeeper

The pattern has many uses. These are the most common:

• lazy initialization (virtual proxy): a heavyweight service object wastes resources by staying alive, but you need it only sometimes. Create it when it is first needed.
• access control (protection proxy): only specific clients may use the service. The proxy passes a request on only if the client's credentials match.
• local execution of a remote service (remote proxy): the service lives on another server. The proxy sends requests over the network and handles the networking details.
• logging requests (logging proxy): you need a history of requests to the service. The proxy logs each request before passing it on.
• caching results (caching proxy): you need to cache client requests and manage the cache's life cycle, especially for large results. The proxy can key the cache by request parameters.
• smart reference: you need to dismiss a heavyweight object once no client uses it. The proxy tracks the clients that hold the service or its results, checks whether they are still active, and releases the service when none are left. It can also track whether a client modified the service, so unmodified objects can be reused.

Implement it in five steps

Refactor existing code toward the pattern in this order:

1. If there is no service interface yet, create one so the proxy and the service are interchangeable. Extracting an interface is not always possible, because every client would have to change. The fallback is to make the proxy a subclass of the service, so it inherits the service's interface.
2. Create the proxy class with a field that references the service. Usually the proxy creates and manages the service's whole life cycle. Occasionally the client passes the service in through the constructor.
3. Implement the proxy methods for your purpose. In most cases the proxy does its work, then delegates to the service.
4. Consider a creation method that decides whether a client gets a proxy or the real service. It can be a simple static method on the proxy or a full factory method.
5. Consider lazy initialization for the service object.

Name what it costs

You gain	You pay
Control the service object without clients knowing	More classes, so the code gets more complicated
Manage the service's life cycle when clients do not care about it	Responses from the service might be delayed
The proxy works even if the service is not ready or not available	Caching and network behavior can change what callers observe
New proxies without changing the service or clients (open/closed)	Initialization failures and concurrent first calls need explicit rules

Do not confuse it with its neighbors

Pattern	How it relates
Adapter	Adapter gives the wrapped object a different interface. Proxy gives it the same interface. Decorator gives it an enhanced interface.
Decorator	Similar structure, both based on delegation. A proxy usually manages its service's life cycle on its own. A decorator's composition is always controlled by the client.
Facade	Both buffer a complex entity and can initialize it on their own. Unlike a facade, a proxy has the same interface as its service, so the two are interchangeable.

Retrieve and apply

Name one proxy policy and the service promise it must preserve. Continue to Chain of Responsibility to route a request through handlers.