Proxy: The Control Intermediary
Provide a substitute that controls access to another object — use for lazy loading, access control, logging, or caching without changing the real object.
Why this matters
Sometimes you cannot or should not access an object directly — it may be expensive to initialize, require access control, live on a remote server, or need logging on every call. The Proxy pattern places an intermediary in front of the real object. Both the proxy and the real object implement the same interface, so callers are unaware they are talking to a substitute. The real object is only involved when the proxy decides it needs to be.
Types of proxies
There are four common proxy variants: Virtual (lazy loading — create the real object only on first use), Protection (access control — check permissions before delegating), Caching (memoize results — avoid repeating expensive calls), and Remote (represent an object on a different machine — gRPC stubs and REST clients are proxies). All share the same structure: same interface, wraps the real object, adds behavior without changing it.
💡Key takeaway
Proxy is the pattern of 'don't pay until you use it' — wrap the expensive object and control when, how many times, or who can access it.
🔧 Some exercises may still have errors. If something seems wrong, use the Feedback button (bottom-right of the page) to report it — it helps us fix it fast.
Hint: Proxy is the pattern of 'don't pay until you use it' — wrap the expensive object and control when, how many times, or who can access it.
✗ Your version