Proxy Pattern
Place a surrogate in front of a real object to control access and add behaviour such as security checks, lazy initialisation, caching or remote communication.
Concept Overview
The Proxy pattern provides a surrogate or placeholder for another object to control access to it. The proxy and real subject implement the same interface, so the client can use either through the same contract. The proxy decides whether and when to delegate to the real subject and can add behaviour before or after delegation, such as access control, lazy loading, caching, logging or remote communication.
1. The problem: direct access is not always desirable
A client may want to use an object but require controlled access. The real object may be expensive to create, remote, sensitive or costly to call. Direct construction and access can make every client responsible for security checks, caching or resource-management rules. The Proxy pattern moves those concerns into a substitute that preserves the same interface as the real object.
2. Participants and their collaboration
The Subject interface defines the common operation. The Real Subject performs the actual work. The Proxy implements the same Subject interface and holds a reference to the Real Subject. The Client uses the Subject abstraction, so it can interact with the proxy without depending on a concrete proxy or real implementation. The proxy controls whether to delegate and what additional behaviour should occur.
interface Service {
void request();
}
final class RealService implements Service {
public void request() {
System.out.println("Performing real work...");
}
}
final class ServiceProxy implements Service {
private final Service real = new RealService();
private final boolean hasAccess;
ServiceProxy(boolean hasAccess) {
this.hasAccess = hasAccess;
}
public void request() {
if (!hasAccess) {
throw new SecurityException("Access denied");
}
real.request();
}
}3. Common proxy types
A virtual proxy delays creation of an expensive object until it is needed. A protection proxy checks permissions before allowing an operation. A remote proxy represents an object in another process or machine and handles communication. A cache proxy returns cached results when valid. A copy-on-write proxy delays copying until a modification occurs. A synchronisation proxy coordinates concurrent access to a shared object. These are variations of the same substitution-and-delegation structure; their internal policies differ.
4. Proxy versus Decorator versus Adapter
Proxy preserves the same interface to control access to the underlying object. Decorator also preserves the interface, but its main intent is to add responsibilities that can be composed around an object. Adapter changes an interface so an incompatible component can be used by a client. These patterns can look structurally similar because all may use composition and delegation, but their design intent is different. Identify the problem being solved before choosing the pattern name.
5. When to use Proxy and what it does not do
Use Proxy when access to an object must be controlled, object creation should be delayed, results can be safely cached, remote access must be represented locally, or cross-cutting access behaviour should be centralised. Proxy does not automatically add new business functionality to the real subject; it adds an access layer. Be careful that caching rules, permission checks and remote error handling do not change the semantics expected by clients.
Key Takeaways
- ✓Proxy implements the same interface as the real subject and controls delegation.
- ✓Common uses include protection, virtual/lazy, remote, cache and synchronisation proxies.
- ✓Proxy controls access; Decorator adds responsibilities; Adapter changes an interface.
- ✓The proxy must preserve the contract and error semantics expected by the client.