Il problema: oggetti pesanti che non servono subito
Hai un modello Article con una relazione comments(). La pagina del blog elenca 20 articoli con titolo, data e autore. Nessuno ha ancora cliccato su un articolo per vederne i commenti, eppure il codice carica tutte le relazioni in anticipo, eseguendo 21 query (una per gli articoli e una per i commenti di ciascuno). E il classico N+1 problem, ma la radice e più profonda: il problema e che l'oggetto Article espone direttamente i commenti, e chi lo usa non ha modo di decidere quando caricarli.
Il Proxy Pattern risolve questo problema interponendo un oggetto surrogato (il proxy) tra il client e l'oggetto reale. Il proxy implementa la stessa interfaccia dell'oggetto reale, ma controlla quando e come l'oggetto reale viene creato o acceduto. Il client non sa di parlare con un proxy — per lui e lo stesso oggetto di sempre.
Cos'e il Proxy Pattern: definizione e varianti
Il Gang of Four definisce il Proxy come un pattern strutturale che "fornisce un surrogato o segnaposto per un altro oggetto per controllarne l'accesso". La struttura e simile al Decorator — entrambi wrappano un oggetto con la stessa interfaccia — ma l'intento e diverso: il Decorator aggiunge comportamento, il Proxy controlla l'accesso.
