Pattern Proxy

Summary un design pattern che crea un livello di indirezione all'accesso di un oggetto dove inserirci della logica di accesso.

Conosciuto anche come

Surrogate.

In base all'uso che ne viene fatto viene chiamato anche come Virtual Proxy, Remote Proxy, Access Proxy o equivalentemente Protection Proxy, Smart Proxy.

Intento

Il design pattern Proxy fornisce un oggetto surrogato (Proxy) di un altro oggetto reale (RealSubject) tramite cui controllare l'accesso a quest'ultimo attraverso della logica di accesso (metodo Request) che viene eseguita in modo trasparente a chi accede all'oggetto reale (Client).

L'oggetto surrogato Proxy viene associato all'oggetto reale RealSubject run-time quindi questo design pattern è classificato rispetto allo scopo (vedi ClassificazioneDeiDesignPattern#ClassiOggetti) come rivolto agli oggetti. Rispetto al fine questo questo design pattern è classificato tra i ClassificazioneDeiDesignPattern#Strutturali .

Diagramma UML

Un'altro diagramma equivalente qui .

Motivazione

La creazione di alcuni oggetti può essere molto onerosa in termini di tempo o di risorse necessarie, in questo caso un oggetto proxy surrogato può essere usato al posto di quello reale e il costo di creazione può essere posticipato sino a quando improrogabile, ad esempio solo quando verrà chiamato quel metodo o acceduta quella proprietà che richiede la parte costosa della operazione di creazione. La logica di creazione posticipata è inserita nell'oggetto proxy invece di essere a carico del codice che crea l'oggetto e duplicata ad ogni creazione.

Quando è necessario accedere ad oggetti che sono in esecuzione in un altro processo (equivalentemente un altro application domain di .NET) o sono in esecuzione in un altro Server un oggetto proxy surrogato può essere usato al posto dell'oggetto reale per rendere trasparente la logica di comunicazione e trasmissione di accesso remoto all'oggetto.

L'esecuzione di alcuni metodi di un oggetto puo essere subordinata ad autorizzazione e l'accesso ad alcume proprietè subordinata a controlli di riservatezza, in questo caso un oggetto proxy surrogato può essere usato per attuare le politiche di sicurezza.

Infine quando si desidera contare i riferimenti attivi ad un oggetto per mettere in atto la terminazione automatica così come faceva Visual Basic per gli oggetti COM, un oggetto proxy surrogato può essere usato al posto di quello reale per tenete conto delle istanziazione e delle distrusioni.

Il design pattern Proxy risolve tutte queste esigenze.

Esempi d'uso in .NET

In .NET il Remoting di oggetti remotizzati per riferimento avviene applicando i l design pattern Proxy con le classe RealProxy tramite cui dinamicamente a run-time viene creato il Proxy dell'oggetto remotizzato.

Anche l'accesso ai Web Methods di un Web Service avviene attraverso un proxy.

Note sulla implementazione in .NET

.NET internamente dispone di una infrastruttura che permette di creare dinamicamente un proxy fruttando la Reflection, CodeDom e ReflectionEmit; inoltre esistono diversi progetti che mettono a disposizone del programmatore funzioni simili

DinamicProxy
NMock intenamente fa uso di Proxy dinamici

.NET non usa un oggetto proxy surrogato per attuare le politiche di sicurezza, invece la Code Access Security fa uso degli attributi, uno degli idiomi del C# (TipiDiPattern#Idiomi).

Del codice .NET di esempio è disponibile qui .

Relazione con altri design pattern

Vedi la mappa della RelazioneTraDesignPattern.

Approfondimenti

Domande di approfondimento

In che modo il design pattern Proxy semplifica il codice?
Quali sono le differenze tra il design pattern Proxy e il PatternAdapter? E le similitudini?
Quali sono le differenze tra il design pattern Proxy e il PatternDecorator? E le similitudini?

Link

VediAnche CatalogoDeiDesignPattern, DesignPattern#PatternComuni