Proxy: The Celebrity Manager Pattern

#pattern #dotnet

You want to meet a famous celebrity. You don't walk straight up to them — you go through their manager. And the manager quietly does a few things: checks whether you're allowed in, decides whether now is a good time, remembers you already asked the same thing yesterday, and logs that you visited.

To you, talking to the manager feels like talking to the celebrity — same conversation, same interface. But the manager sits in the middle and controls access.

That's the Proxy pattern: a stand-in that looks identical to the real object but controls access to it.

The key idea

The proxy implements the same interface as the real object, so the caller can't tell the difference — it thinks it's talking to the real thing.

public interface IImageService
{
    byte[] GetImage(string id);
}

// The real object — expensive to use
public class RealImageService : IImageService
{
    public byte[] GetImage(string id)
    {
        Console.WriteLine("Loading image from disk/cloud... (slow!)");
        return new byte[1000]; // heavy load
    }
}

Now the proxy: same interface, wraps the real one, and adds control.

public class CachingImageProxy : IImageService
{
    private readonly RealImageService _real = new();
    private readonly Dictionary<string, byte[]> _cache = new();

    public byte[] GetImage(string id)
    {
        if (_cache.ContainsKey(id))
        {
            Console.WriteLine("Returning from cache (fast!)");
            return _cache[id];              // skip the real object entirely
        }

        var image = _real.GetImage(id);     // only hit the real one when needed
        _cache[id] = image;
        return image;
    }
}

The caller has no idea a proxy is involved:

IImageService service = new CachingImageProxy();
service.GetImage("logo");   // slow — loads for real, then caches
service.GetImage("logo");   // fast — served from cache, real object untouched

The four flavors of Proxy

Same structure every time, different job:

Virtual Proxy — delays creating an expensive object until it's actually needed (lazy loading). Don't load the 4K image until someone scrolls to it.
Protection Proxy — checks permissions before allowing access. Are you an admin? No? Denied.
Caching Proxy — stores results to avoid repeat work (the example above).
Remote Proxy — stands in for an object that lives on another server, hiding the network call. An API client class is essentially this.

The confusing part: Proxy vs Decorator vs Adapter

All three wrap an object using the same "implement the interface, hold an inner object" structure. The difference is intent:

Adapter holds a differently-shaped object and makes it fit — it changes the interface.
Decorator holds the same interface and adds behavior — you stack features.
Proxy holds the same interface and controls access to the real one.

There's a clean behavioral tell at runtime. A decorator always calls the inner object and adds something around it. A proxy might not call the real object at all — a cache hit returns early, a denied permission stops cold. Decorator enhances; Proxy guards.

Where you've already seen it

Lazy loading in EF Core — access order.Customer and a DB query silently fires. That Customer was a proxy.
API client classes — apiClient.GetUser() looks like a local method but is a remote proxy over an HTTP call.
Lazy<T> — a virtual proxy: the object isn't created until you touch .Value.

One line to remember

Proxy = the celebrity's manager. Same conversation as the real thing, but it controls who gets through, when, and whether the real object is even bothered.

Part 7 of a series on must-know design patterns in C#, explained the simple way. Earlier parts covered Singleton, Factory Method, Builder, Adapter, Decorator, and Facade. Next up: Composite — the folder-and-files pattern.

DEV Community