Go Proxy Pattern

What It Is

The Proxy pattern puts a stand-in with the same interface in front of a real object. Callers talk to the proxy as if it were the real thing; the proxy decides when and how to involve the original.

Common jobs for a proxy: caching answers, checking access, delaying expensive creation, counting calls.

Example: A Caching Proxy

The real weather service is slow. The proxy answers repeated questions from its cache and only calls the service for new ones — behind the very same interface.

The stand-in that remembers

The first Paris question reaches the remote service; the second is answered from the cache — the "calling the remote service" line prints only once.

Write a Go program with a caching Proxy: a Weather interface (Forecast method), a WeatherService that prints when it calls the remote service, and a CachedWeather proxy that stores answers in a map and serves repeats from cache. Ask for the same city twice and print both answers.

> Output: Go program and captured output

Prompt

Write a Go program with a caching Proxy: a Weather interface (Forecast method), a WeatherService that prints when it calls the remote service, and a CachedWeather proxy that stores answers in a map and serves repeats from cache. Ask for the same city twice and print both answers.

Output: Go program and captured output

package main

import "fmt"

type Weather interface {
  Forecast(city string) string
}

// The real service is slow and expensive.
type WeatherService struct{}

func (WeatherService) Forecast(city string) string {
  fmt.Println("  (calling the remote service...)")
  return "sunny in " + city
}

// The proxy stands in front and caches answers.
type CachedWeather struct {
  service WeatherService
  cache   map[string]string
}

func (c *CachedWeather) Forecast(city string) string {
  if answer, ok := c.cache[city]; ok {
    return answer + " (from cache)"
  }
  answer := c.service.Forecast(city)
  c.cache[city] = answer
  return answer
}

func main() {
  w := &CachedWeather{cache: map[string]string{}}

  fmt.Println(w.Forecast("Paris"))
  fmt.Println(w.Forecast("Paris"))
}

When to Use It

Use it to add caching, access control, laziness or metering in front of something you cannot or should not change — especially remote or expensive resources.

Skip it when you own the object and the behavior belongs inside it. A proxy is for controlling access; a decorator is for adding behavior in layers — pick the intent that matches.

Pros and Cons

Pros: callers need no changes at all; expensive work is skipped or controlled in one place.

Cons: hidden behavior — a caller may get a cached answer without knowing; stale caches and surprise denials are debugged behind an innocent-looking interface.