System Design LLDStructural Patterns

Proxy Pattern

LevelIntermediate

Duration90 mins

TopicStructural Patterns

1 / 4

Problem — Controlling Access to Object

The Access Control Dilemma

In software systems, we often face a fundamental tension: clients need access to objects, but direct access creates problems. Whether it's a resource-intensive object that shouldn't be created until absolutely necessary, a sensitive object that requires authorization before access, or an object residing on a remote server, direct instantiation and interaction often prove inadequate or dangerous.

Consider these scenarios from real production systems:

A document editor loads high-resolution images. Users scroll through a 50-page document with hundreds of images. Loading all images upfront would consume gigabytes of memory and take minutes to open.
An enterprise application connects to critical database servers. Not every user should have the ability to execute destructive queries—access must be controlled based on roles and permissions.
A distributed system communicates with services on remote machines. The client code shouldn't be burdened with network protocols, connection management, or failure handling.
A caching layer wraps expensive computation. Before invoking the real computation, the system should check if a cached result exists.

In each case, placing logic between the client and the real object provides the solution.

What You Will Learn

By the end of this page, you will understand the core problem that the Proxy pattern solves—why direct access to objects becomes problematic and what types of access control are commonly needed. You'll recognize proxy-eligible scenarios in your own systems and understand why a separate intermediary object provides the cleanest solution.

The Direct Access Problem

When clients directly instantiate and interact with objects, they become tightly coupled to:

Object creation timing — The client decides when objects are created
Object location — The client assumes objects exist in the same process/memory space
Access privileges — No validation occurs before operations execute
Resource management — No opportunity for optimization, caching, or lifecycle management

This direct coupling works fine for simple scenarios, but breaks down as systems grow in complexity, scale across networks, or require security controls.

Let's examine a concrete example:

direct-access-problem.ts
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
// A resource-intensive document renderer
class DocumentRenderer {
    private documentData: Uint8Array;
    private parsedPages: Map<number, PageContent> = new Map();
    
    constructor(private documentPath: string) {
        // PROBLEM: Constructor loads entire document immediately
        // For a 500MB PDF, this blocks for seconds
        console.log(`Loading document from ${documentPath}...`);
        this.documentData = this.loadEntireDocument(documentPath);
        this.parseAllPages();
    }
    
    private loadEntireDocument(path: string): Uint8Array {
        // Simulates reading entire file into memory
        // For large files, this is expensive!
        return readFileSync(path);
    }
    
    private parseAllPages(): void {
        // Parses every page upfront
        // User might only view page 1!
        for (let i = 0; i < this.getPageCount(); i++) {
            this.parsedPages.set(i, this.parsePage(i));
        }
    }
    
    renderPage(pageNumber: number): Canvas {
        return this.renderFromParsed(this.parsedPages.get(pageNumber)!);
    }
}
 
// Client code - tightly coupled to eager loading
class DocumentViewer {
    private renderers: Map<string, DocumentRenderer> = new Map();
    
    openDocument(path: string): void {
        // PROBLEM: Every document is fully loaded when "opened"
        // User might just be browsing thumbnails!
        const renderer = new DocumentRenderer(path);
        this.renderers.set(path, renderer);
    }
    
    viewPage(path: string, page: number): Canvas {
        return this.renderers.get(path)!.renderPage(page);
    }
}
 
// Usage: Opening 10 documents loads 5GB of data immediately
const viewer = new DocumentViewer();
const documents = getRecentDocuments(); // Returns 10 paths
documents.forEach(doc => viewer.openDocument(doc)); // Blocks for 30+ seconds!

The problems in this design are severe:

Memory explosion: Opening 10 large documents consumes gigabytes of RAM
Startup latency: Users wait 30+ seconds before the application responds
Wasted resources: Most pages are never viewed, but all are parsed
No control point: We can't add caching, access control, or monitoring without modifying the core class

The Naive Solution Won't Scale

You might think 'just make loading lazy with optional parameters'. But this pollutes the interface, requires all clients to understand the lazy loading protocol, and couples optimization concerns to business logic. We need a solution that keeps the real object unchanged while providing controlled access.

Categories of Access Control Needs

Access control needs fall into several distinct categories, each presenting unique challenges. Understanding these categories helps us recognize when a proxy-based solution is appropriate.

2.1 Resource Management (Lazy Initialization)

Some objects are expensive to create but may never be used, or their creation should be deferred until absolutely necessary.

Lazy Initialization Scenarios

•Large file loading — Documents, images, videos that consume significant memory
•Database connections — Connection pools where connections shouldn't be opened until needed
•Complex computations — Machine learning models, scientific simulations, rendering engines
•External service clients — API clients that require authentication handshakes
•Hardware resources — Camera streams, audio devices, GPU contexts

2.2 Security and Authorization

Not all clients should have equal access to all operations. Access must be validated, logged, and potentially denied.

Authorization Control Scenarios
Scenario	Protection Need	Without Proxy
Admin dashboard	Only admin users can access sensitive operations	Security checks scattered throughout codebase
Banking transactions	Amounts above threshold require additional verification	Business logic mixed with security logic
Document sharing	Read vs write permissions per user	Permission checks duplicated in every method
Multi-tenant system	Tenant A cannot access Tenant B's data	Tenant isolation logic everywhere
Rate limiting	Users limited to N requests per minute	Rate limiting code in every endpoint

2.3 Location Transparency (Remote Access)

In distributed systems, objects may reside on different machines. Clients shouldn't need to know or care about object location.

remote-access-problem.ts
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
// Without location transparency, clients handle networking directly
class OrderServiceClient {
    async placeOrder(order: Order): Promise<OrderResult> {
        // Client is burdened with:
        // 1. URL construction
        const url = `https://${this.host}:${this.port}/api/orders`;
        
        // 2. Serialization
        const body = JSON.stringify(order);
        
        // 3. Network call with timeout/retry
        const response = await fetch(url, {
            method: 'POST',
            body,
            headers: { 'Content-Type': 'application/json' },
            signal: AbortSignal.timeout(5000),
        });
        
        // 4. Error handling
        if (!response.ok) {
            throw new NetworkError(`Order failed: ${response.status}`);
        }
        
        // 5. Deserialization
        return await response.json() as OrderResult;
    }
    
    // Every method repeats this pattern!
    async cancelOrder(orderId: string): Promise<void> { /* ... */ }
    async getOrderStatus(orderId: string): Promise<OrderStatus> { /* ... */ }
}
 
// Ideal: Client shouldn't know OrderService is remote
interface OrderService {
    placeOrder(order: Order): Promise<OrderResult>;
    cancelOrder(orderId: string): Promise<void>;
    getOrderStatus(orderId: string): Promise<OrderStatus>;
}

2.4 Smart References (Additional Functionality)

Sometimes we need to add behavior when objects are accessed—logging, caching, reference counting, synchronization—without modifying the object itself.

Smart Reference Use Cases

•Logging proxy — Record all method calls for debugging or auditing
•Caching proxy — Cache expensive operation results transparently
•Synchronization proxy — Add thread-safety to non-thread-safe objects
•Reference counting proxy — Track object usage for garbage collection or resource management
•Copy-on-write proxy — Delay expensive copies until modification occurs

Why Not Just Modify the Original Class?

A reasonable question emerges: Why not simply add lazy loading, access control, and caching directly to the original class?

This approach seems simpler at first glance, but it violates fundamental design principles and creates long-term maintenance problems.

Problems with Modifying Original Class

•Single Responsibility Violation — Class now handles business logic AND access control AND caching AND logging
•Open-Closed Violation — Adding new access control types requires modifying the class
•Testing Complexity — Cannot test business logic in isolation from access control
•Inflexibility — Cannot have different access policies for different clients
•Library Classes — Cannot modify third-party code at all

Benefits of Separate Proxy

•Separation of Concerns — Each class has one clear responsibility
•Composability — Stack multiple proxies for combined behaviors
•Testability — Test each concern independently
•Flexibility — Use different proxies for different clients
•Third-party Compatible — Wrap any class without modification

god-class-antipattern.ts
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
// ANTI-PATTERN: Mixing concerns in original class
class ImageRenderer {
    private image: ImageData | null = null;
    private cache: Map<string, Canvas> = new Map();
    private accessLog: AuditLog;
    private rateLimiter: RateLimiter;
    
    constructor(
        private imagePath: string,
        private user: User,              // Access control concern
        private cacheEnabled: boolean,   // Caching concern
        private loggingEnabled: boolean, // Logging concern
    ) {
        this.accessLog = new AuditLog();
        this.rateLimiter = new RateLimiter(100);
    }
    
    render(width: number, height: number): Canvas {
        // Logging concern mixed in
        if (this.loggingEnabled) {
            this.accessLog.record(this.user, 'render', { width, height });
        }
        
        // Access control concern mixed in
        if (!this.user.hasPermission('render:images')) {
            throw new UnauthorizedError('User cannot render images');
        }
        
        // Rate limiting concern mixed in
        if (!this.rateLimiter.allow(this.user.id)) {
            throw new RateLimitError('Too many requests');
        }
        
        // Caching concern mixed in
        const cacheKey = `${width}x${height}`;
        if (this.cacheEnabled && this.cache.has(cacheKey)) {
            return this.cache.get(cacheKey)!;
        }
        
        // Lazy loading concern mixed in
        if (!this.image) {
            this.image = this.loadImage();
        }
        
        // FINALLY: Actual business logic
        const result = this.doRender(this.image, width, height);
        
        // More caching logic
        if (this.cacheEnabled) {
            this.cache.set(cacheKey, result);
        }
        
        return result;
    }
    
    private doRender(image: ImageData, width: number, height: number): Canvas {
        // The actual rendering - 10 lines buried in 50+ lines of concerns
    }
}

The God Class Trap

When a class handles too many concerns, it becomes a 'god class'—difficult to understand, impossible to test in isolation, and terrifying to modify. Every change risks breaking unrelated functionality. The proxy pattern provides an escape hatch from this trap.

The Core Insight — Interposition

The Proxy pattern is built on a powerful idea: interposition. Instead of clients accessing objects directly, we insert an intermediary that:

Presents the same interface as the real object (clients don't know they're talking to a proxy)
Controls access to the real object based on any criteria we choose
Adds functionality before or after delegating to the real object
Maintains transparency — the client's code doesn't change

This interposition creates a seam in the system—a point where behavior can be modified without touching either the client or the real object.

Converting Mermaid diagram...

The proxy becomes a gatekeeper, but one that speaks the same language as the object it guards. Clients continue using familiar interfaces; they simply don't realize they're talking to a representative rather than the principal.

This concept appears throughout computing:

Web proxies intercept HTTP requests, adding caching, filtering, or logging
Database connection pools are proxies managing actual database connections
API gateways proxy requests to backend services
Virtual memory is the operating system proxying access to physical memory

The Transparency Principle

A well-designed proxy is indistinguishable from the real object to client code. If clients must know whether they're using a proxy or the real object, the abstraction has leaked. Strive for substitutability—any place expecting the real object should accept the proxy.

Real-World Problem Scenarios Deep Dive

Let's examine detailed real-world scenarios where uncontrolled object access creates significant problems. These scenarios will reappear throughout this module as we apply the Proxy pattern to solve them.

Scenario: Video Streaming Platform

A video streaming service displays a catalog of thousands of videos. Each video has associated metadata, thumbnails, and the actual video stream.

Problems with Direct Access

•Memory explosion: Loading all video objects for a catalog page would consume gigabytes of RAM (actual video data)
•Startup latency: Users would wait minutes for the catalog to render
•Bandwidth waste: Video data pre-fetched for unwatched content wastes network resources
•No access control: Premium content might be served to free-tier users

TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
// Problem: Video object loads stream on construction
class Video {
    private stream: VideoStream;
    private metadata: VideoMetadata;
    
    constructor(videoId: string) {
        this.metadata = fetchMetadata(videoId);     // Quick
        this.stream = loadVideoStream(videoId);      // SLOW - 100MB+
    }
    
    getTitle(): string { return this.metadata.title; }
    play(): void { this.stream.start(); }
}
 
// Catalog loads ALL videos - disaster!
class VideoCatalog {
    private videos: Video[] = [];
    
    constructor() {
        for (const id of getAllVideoIds()) {    // 10,000 videos
            this.videos.push(new Video(id));    // 1TB loaded!
        }
    }
}

Recognizing Proxy Opportunities

How do you recognize when a Proxy pattern would benefit your design? Look for these diagnostic questions and code smells:

Diagnostic Questions

•Timing: Should object creation be deferred until first use? Is the constructor expensive?
•Location: Does the object reside on a different machine? Does the client need location transparency?
•Permission: Should different clients have different access levels? Are there operations that require authorization?
•Monitoring: Do you need to log, count, or audit all interactions with this object?
•Optimization: Could caching, pooling, or lazy evaluation improve performance transparently?
•Transformation: Should data be validated, encrypted, or transformed before reaching the object?

Code smells that suggest proxy need:

Code Smells Indicating Proxy Need
Code Smell	Symptom	Proxy Type
Repeated null checks	`if (this.heavyObject === null) { this.heavyObject = createHeavy(); }`	Virtual Proxy
Permission checks in every method	`if (!user.can('read')) throw UnauthorizedError;`	Protection Proxy
Network code scattered everywhere	`const response = await fetch(url);`	Remote Proxy
Identical caching logic repeated	`const cached = this.cache.get(key); if (cached) return cached;`	Caching Proxy
Logging statements everywhere	`console.log('Entering method X');`	Logging Proxy

The Proxy Litmus Test

If you find yourself adding code BEFORE or AFTER method calls that isn't part of the core business logic, you're a candidate for the Proxy pattern. This cross-cutting code should live in a proxy, not pollute the original class or every call site.

Summary: The Case for Controlled Access

We've established that direct object access, while simple, creates significant problems as systems grow in complexity:

Key Takeaways

•Direct access couples clients to object creation timing, location, and lifecycle management
•Access control falls into four categories: lazy initialization, security/authorization, remote access, and smart references
•Modifying original classes to add access control violates SRP and creates god classes
•Interposition — placing an intermediary between client and object — provides a clean solution
•Proxies present the same interface as real objects, maintaining client code compatibility
•Recognize proxy opportunities through diagnostic questions and code smells

What's Next:

Now that we understand the problem space, the next page introduces the Proxy pattern's solution: the surrogate with the same interface. We'll see how creating a stand-in object that implements the same interface as the real object provides the control point we need while maintaining complete transparency to client code.

Page Complete

You now understand why direct object access becomes problematic and the types of access control commonly needed. Next, we'll explore how the Proxy pattern structures its solution using a surrogate that shares the real object's interface.

1 / 4

Loading learning content...

System Design LLDStructural Patterns

Proxy Pattern

LevelIntermediate

Duration90 mins

TopicStructural Patterns

1 / 4

Problem — Controlling Access to Object

The Access Control Dilemma

Consider these scenarios from real production systems:

A document editor loads high-resolution images. Users scroll through a 50-page document with hundreds of images. Loading all images upfront would consume gigabytes of memory and take minutes to open.
An enterprise application connects to critical database servers. Not every user should have the ability to execute destructive queries—access must be controlled based on roles and permissions.
A distributed system communicates with services on remote machines. The client code shouldn't be burdened with network protocols, connection management, or failure handling.
A caching layer wraps expensive computation. Before invoking the real computation, the system should check if a cached result exists.

In each case, placing logic between the client and the real object provides the solution.

What You Will Learn

The Direct Access Problem

When clients directly instantiate and interact with objects, they become tightly coupled to:

Object creation timing — The client decides when objects are created
Object location — The client assumes objects exist in the same process/memory space
Access privileges — No validation occurs before operations execute
Resource management — No opportunity for optimization, caching, or lifecycle management

This direct coupling works fine for simple scenarios, but breaks down as systems grow in complexity, scale across networks, or require security controls.

Let's examine a concrete example:

direct-access-problem.ts
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
// A resource-intensive document renderer
class DocumentRenderer {
    private documentData: Uint8Array;
    private parsedPages: Map<number, PageContent> = new Map();
    
    constructor(private documentPath: string) {
        // PROBLEM: Constructor loads entire document immediately
        // For a 500MB PDF, this blocks for seconds
        console.log(`Loading document from ${documentPath}...`);
        this.documentData = this.loadEntireDocument(documentPath);
        this.parseAllPages();
    }
    
    private loadEntireDocument(path: string): Uint8Array {
        // Simulates reading entire file into memory
        // For large files, this is expensive!
        return readFileSync(path);
    }
    
    private parseAllPages(): void {
        // Parses every page upfront
        // User might only view page 1!
        for (let i = 0; i < this.getPageCount(); i++) {
            this.parsedPages.set(i, this.parsePage(i));
        }
    }
    
    renderPage(pageNumber: number): Canvas {
        return this.renderFromParsed(this.parsedPages.get(pageNumber)!);
    }
}
 
// Client code - tightly coupled to eager loading
class DocumentViewer {
    private renderers: Map<string, DocumentRenderer> = new Map();
    
    openDocument(path: string): void {
        // PROBLEM: Every document is fully loaded when "opened"
        // User might just be browsing thumbnails!
        const renderer = new DocumentRenderer(path);
        this.renderers.set(path, renderer);
    }
    
    viewPage(path: string, page: number): Canvas {
        return this.renderers.get(path)!.renderPage(page);
    }
}
 
// Usage: Opening 10 documents loads 5GB of data immediately
const viewer = new DocumentViewer();
const documents = getRecentDocuments(); // Returns 10 paths
documents.forEach(doc => viewer.openDocument(doc)); // Blocks for 30+ seconds!

The problems in this design are severe:

Memory explosion: Opening 10 large documents consumes gigabytes of RAM
Startup latency: Users wait 30+ seconds before the application responds
Wasted resources: Most pages are never viewed, but all are parsed
No control point: We can't add caching, access control, or monitoring without modifying the core class

The Naive Solution Won't Scale

Categories of Access Control Needs

Access control needs fall into several distinct categories, each presenting unique challenges. Understanding these categories helps us recognize when a proxy-based solution is appropriate.

2.1 Resource Management (Lazy Initialization)

Some objects are expensive to create but may never be used, or their creation should be deferred until absolutely necessary.

Lazy Initialization Scenarios

•Large file loading — Documents, images, videos that consume significant memory
•Database connections — Connection pools where connections shouldn't be opened until needed
•Complex computations — Machine learning models, scientific simulations, rendering engines
•External service clients — API clients that require authentication handshakes
•Hardware resources — Camera streams, audio devices, GPU contexts

2.2 Security and Authorization

Not all clients should have equal access to all operations. Access must be validated, logged, and potentially denied.

Authorization Control Scenarios
Scenario	Protection Need	Without Proxy
Admin dashboard	Only admin users can access sensitive operations	Security checks scattered throughout codebase
Banking transactions	Amounts above threshold require additional verification	Business logic mixed with security logic
Document sharing	Read vs write permissions per user	Permission checks duplicated in every method
Multi-tenant system	Tenant A cannot access Tenant B's data	Tenant isolation logic everywhere
Rate limiting	Users limited to N requests per minute	Rate limiting code in every endpoint

2.3 Location Transparency (Remote Access)

In distributed systems, objects may reside on different machines. Clients shouldn't need to know or care about object location.

remote-access-problem.ts
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
// Without location transparency, clients handle networking directly
class OrderServiceClient {
    async placeOrder(order: Order): Promise<OrderResult> {
        // Client is burdened with:
        // 1. URL construction
        const url = `https://${this.host}:${this.port}/api/orders`;
        
        // 2. Serialization
        const body = JSON.stringify(order);
        
        // 3. Network call with timeout/retry
        const response = await fetch(url, {
            method: 'POST',
            body,
            headers: { 'Content-Type': 'application/json' },
            signal: AbortSignal.timeout(5000),
        });
        
        // 4. Error handling
        if (!response.ok) {
            throw new NetworkError(`Order failed: ${response.status}`);
        }
        
        // 5. Deserialization
        return await response.json() as OrderResult;
    }
    
    // Every method repeats this pattern!
    async cancelOrder(orderId: string): Promise<void> { /* ... */ }
    async getOrderStatus(orderId: string): Promise<OrderStatus> { /* ... */ }
}
 
// Ideal: Client shouldn't know OrderService is remote
interface OrderService {
    placeOrder(order: Order): Promise<OrderResult>;
    cancelOrder(orderId: string): Promise<void>;
    getOrderStatus(orderId: string): Promise<OrderStatus>;
}

2.4 Smart References (Additional Functionality)

Sometimes we need to add behavior when objects are accessed—logging, caching, reference counting, synchronization—without modifying the object itself.

Smart Reference Use Cases

•Logging proxy — Record all method calls for debugging or auditing
•Caching proxy — Cache expensive operation results transparently
•Synchronization proxy — Add thread-safety to non-thread-safe objects
•Reference counting proxy — Track object usage for garbage collection or resource management
•Copy-on-write proxy — Delay expensive copies until modification occurs

Why Not Just Modify the Original Class?

A reasonable question emerges: Why not simply add lazy loading, access control, and caching directly to the original class?

This approach seems simpler at first glance, but it violates fundamental design principles and creates long-term maintenance problems.

Problems with Modifying Original Class

•Single Responsibility Violation — Class now handles business logic AND access control AND caching AND logging
•Open-Closed Violation — Adding new access control types requires modifying the class
•Testing Complexity — Cannot test business logic in isolation from access control
•Inflexibility — Cannot have different access policies for different clients
•Library Classes — Cannot modify third-party code at all

Benefits of Separate Proxy

•Separation of Concerns — Each class has one clear responsibility
•Composability — Stack multiple proxies for combined behaviors
•Testability — Test each concern independently
•Flexibility — Use different proxies for different clients
•Third-party Compatible — Wrap any class without modification

god-class-antipattern.ts
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
// ANTI-PATTERN: Mixing concerns in original class
class ImageRenderer {
    private image: ImageData | null = null;
    private cache: Map<string, Canvas> = new Map();
    private accessLog: AuditLog;
    private rateLimiter: RateLimiter;
    
    constructor(
        private imagePath: string,
        private user: User,              // Access control concern
        private cacheEnabled: boolean,   // Caching concern
        private loggingEnabled: boolean, // Logging concern
    ) {
        this.accessLog = new AuditLog();
        this.rateLimiter = new RateLimiter(100);
    }
    
    render(width: number, height: number): Canvas {
        // Logging concern mixed in
        if (this.loggingEnabled) {
            this.accessLog.record(this.user, 'render', { width, height });
        }
        
        // Access control concern mixed in
        if (!this.user.hasPermission('render:images')) {
            throw new UnauthorizedError('User cannot render images');
        }
        
        // Rate limiting concern mixed in
        if (!this.rateLimiter.allow(this.user.id)) {
            throw new RateLimitError('Too many requests');
        }
        
        // Caching concern mixed in
        const cacheKey = `${width}x${height}`;
        if (this.cacheEnabled && this.cache.has(cacheKey)) {
            return this.cache.get(cacheKey)!;
        }
        
        // Lazy loading concern mixed in
        if (!this.image) {
            this.image = this.loadImage();
        }
        
        // FINALLY: Actual business logic
        const result = this.doRender(this.image, width, height);
        
        // More caching logic
        if (this.cacheEnabled) {
            this.cache.set(cacheKey, result);
        }
        
        return result;
    }
    
    private doRender(image: ImageData, width: number, height: number): Canvas {
        // The actual rendering - 10 lines buried in 50+ lines of concerns
    }
}

The God Class Trap

The Core Insight — Interposition

The Proxy pattern is built on a powerful idea: interposition. Instead of clients accessing objects directly, we insert an intermediary that:

Presents the same interface as the real object (clients don't know they're talking to a proxy)
Controls access to the real object based on any criteria we choose
Adds functionality before or after delegating to the real object
Maintains transparency — the client's code doesn't change

This interposition creates a seam in the system—a point where behavior can be modified without touching either the client or the real object.

Converting Mermaid diagram...

This concept appears throughout computing:

Web proxies intercept HTTP requests, adding caching, filtering, or logging
Database connection pools are proxies managing actual database connections
API gateways proxy requests to backend services
Virtual memory is the operating system proxying access to physical memory

The Transparency Principle

Real-World Problem Scenarios Deep Dive

Scenario: Video Streaming Platform

A video streaming service displays a catalog of thousands of videos. Each video has associated metadata, thumbnails, and the actual video stream.

Problems with Direct Access

•Memory explosion: Loading all video objects for a catalog page would consume gigabytes of RAM (actual video data)
•Startup latency: Users would wait minutes for the catalog to render
•Bandwidth waste: Video data pre-fetched for unwatched content wastes network resources
•No access control: Premium content might be served to free-tier users

TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
// Problem: Video object loads stream on construction
class Video {
    private stream: VideoStream;
    private metadata: VideoMetadata;
    
    constructor(videoId: string) {
        this.metadata = fetchMetadata(videoId);     // Quick
        this.stream = loadVideoStream(videoId);      // SLOW - 100MB+
    }
    
    getTitle(): string { return this.metadata.title; }
    play(): void { this.stream.start(); }
}
 
// Catalog loads ALL videos - disaster!
class VideoCatalog {
    private videos: Video[] = [];
    
    constructor() {
        for (const id of getAllVideoIds()) {    // 10,000 videos
            this.videos.push(new Video(id));    // 1TB loaded!
        }
    }
}

Recognizing Proxy Opportunities

How do you recognize when a Proxy pattern would benefit your design? Look for these diagnostic questions and code smells:

Diagnostic Questions

•Timing: Should object creation be deferred until first use? Is the constructor expensive?
•Location: Does the object reside on a different machine? Does the client need location transparency?
•Permission: Should different clients have different access levels? Are there operations that require authorization?
•Monitoring: Do you need to log, count, or audit all interactions with this object?
•Optimization: Could caching, pooling, or lazy evaluation improve performance transparently?
•Transformation: Should data be validated, encrypted, or transformed before reaching the object?

Code smells that suggest proxy need:

Code Smells Indicating Proxy Need
Code Smell	Symptom	Proxy Type
Repeated null checks	`if (this.heavyObject === null) { this.heavyObject = createHeavy(); }`	Virtual Proxy
Permission checks in every method	`if (!user.can('read')) throw UnauthorizedError;`	Protection Proxy
Network code scattered everywhere	`const response = await fetch(url);`	Remote Proxy
Identical caching logic repeated	`const cached = this.cache.get(key); if (cached) return cached;`	Caching Proxy
Logging statements everywhere	`console.log('Entering method X');`	Logging Proxy

The Proxy Litmus Test

Summary: The Case for Controlled Access

We've established that direct object access, while simple, creates significant problems as systems grow in complexity:

Key Takeaways

•Direct access couples clients to object creation timing, location, and lifecycle management
•Access control falls into four categories: lazy initialization, security/authorization, remote access, and smart references
•Modifying original classes to add access control violates SRP and creates god classes
•Interposition — placing an intermediary between client and object — provides a clean solution
•Proxies present the same interface as real objects, maintaining client code compatibility
•Recognize proxy opportunities through diagnostic questions and code smells

What's Next:

Page Complete

1 / 4