1. Struttura
1.1. Proxy
1.1.1. mantiene un reference che gli consente di accedere all'oggetto reale
1.1.2. aderisce all'interfaccia del Subject, in modo da poter essere usato al posto del RealSubject
1.1.3. controlla l'accesso all'oggetto reale
1.1.3.1. puo' avere la responsabilita' di crearlo e cancellarlo
1.1.4. altre responsabilita' dipendono dal tipo di proxy
1.1.4.1. il remote proxy e' responsabile dell'encoding del messaggio e dei suoi parametri e per il loro invio all'oggetto reale, che e' remoto
1.1.4.2. il virtual proxy potrebbe avere la responsabilita' di tenersi una cache con informazioni dell'oggetto originale, in modo da poter postporre il piu' possibile l'accesso a quest'ultimo
1.1.4.2.1. es: l'ImageProxy si conserva la dimensione di una RealImage
1.1.4.3. il protection proxy e' responsabile di controllare se il chiamante ha i diritti necessari per invocare il messaggio sull'oggetto reale
1.2. Subject
1.2.1. definisce una interfaccia comune a RealSubject e Proxy, in modo che questi possa essere usato in tutti i posti in cui ci si aspetta un RealSubject
1.3. RealSubject
1.3.1. definisce l'oggetto reale, il cui accesso e' mediato dal Proxy
2. Conseguenze
2.1. il proxy introduce un livello di indirezione nell'accesso ad un oggetto
2.1.1. questa indirezione puo' essere usata per diversi scopi
2.1.1.1. un remote proxy nasconde il fatto che l'oggetto e' remoto
2.1.1.2. un virtual proxy consente di realizzare ottimizzazioni come la creazione on demand dell'oggetto reale
2.1.1.3. protection proxy e smart reference consentono di realizzare servizi aggiuntivi quando si accede all'oggetto reale
3. Implementazione
3.1. E' possibile implementare il proxy pattern sfruttando le feature del linguaggio usato
3.1.1. in C++ si puo' fare l'overloading dell'operatore di accesso ai membri, ->
3.1.1.1. utile magari per realizzare smart reference proxy
3.1.1.2. non va bene pero' per tutti i tipi di proxy perche' non consente di distinguere tra metodi invocati
3.1.2. in Smalltalk si puo' usare doesNotUnderstand: per rigirare automaticamente le richieste all'oggetto reale
3.1.2.1. Smalltalk invoca il metodo doesNotUnderstand: aMessage quando un client manda un messaggio ad un receiver che non ha un metodo corrispondente
3.1.2.1.1. il proxy puo' allora ridefinire doesNotUnderstand in modo che il messaggio sia girato al suo oggetto reale
3.1.2.2. una cosa simile si puo' fare anche in Ruby
3.1.3. in Java si possono usare le API del Dynamic Proxy
3.2. In alcuni casi il proxy non deve conoscere il tipo esatto dell'oggetto da lui puntato
3.2.1. in questi casi il proxy puo' riferirsi al subject attraverso una interfaccia astratta
3.2.1.1. e quindi non e' necessario creare un proxy per ogni tipo concreto di RealSubject
3.2.1.2. questo approccio non va bene pero' nei casi in cui il proxy deve poter istanziare il RealSubject (virtual proxy)
3.2.1.2.1. e quindi deve conoscere il suo tipo esatto
3.3. il Proxy deve avere un qualche riferimento indiretto ma univoco al RealSubject prima che sia istanziato, in modo da potervi accedere quando serve
3.3.1. Nell'esempio di Virtual Proxy del GOF, il reference all'Image è attraverso il nome del file dove l'immagine è salvata
3.3.2. Il Remote Proxy potrebbe puntare al RealSubject remoto attraverso un URI
4. Dubbi e issues
4.1. Nel sample code in C++ del GOF il client sa di usare un proxy, mentre non sempre e' cosi'
5. Pattern correlati
5.1. Adapter
5.1.1. fornisce una interfaccia diversa al RealSubject incapsulato
5.2. Decorator
5.2.1. simile struttura
5.2.2. diverso scopo
5.2.2.1. nel Decorator si vuole aggiungere comportamento all'oggetto incapsulato
5.2.2.2. nel Proxy si controlla l'accesso all'oggetto incapsulato
5.3. Facade
6. Reference
6.1. http://www.mip.sdu.dk/~bnj/designpatterns/hires/pat4g.htm
6.2. http://c2.com/cgi/wiki?ProxyPattern
6.3. http://home.earthlink.net/~huston2/dp/proxy.html
6.4. http://wiki.cs.uiuc.edu/patternStories/ProxyPattern
6.5. http://wiki.java.net/bin/view/Javapedia/ProxyPattern
6.6. http://wiki.ugidotnet.org/default.aspx/UGIdotNETWiki/PatternProxy.html
7. Intento
7.1. Fornire un surrogato di un altro oggetto, per poter controllare l'accesso a quest'ultimo
7.2. Introdurre un ulteriore livello di indirezione, per offrire un accesso controllato/distribuito/intelligente
7.3. fa parte degli Structural Patterns
8. Motivazioni
8.1. Uno dei motivi per cui potremmo aver bisogno di controllare l'accesso ad un oggetto e' quello di ritardare il piu' possibile la sua creazione e inizializzazione, fino a quando non sia realmente necessaria
8.1.1. perche' le operazioni di costruzione e inizializzazione di un oggetto possono essere molto costose e quindi conviene farle solo quando sono realmente necessarie
8.1.1.1. Approccio lazy
8.1.2. Esempio dell'editor di documenti
8.1.2.1. L'editor consente di inserire nei documenti degli oggetti grafici
8.1.2.1.1. per esempio delle grosse immagini
8.1.2.1.2. tali oggetti grafici possono essere costosi da creare
8.1.2.2. Aprire un documento dovrebbe pero' essere un'operazione veloce
8.1.2.2.1. percio' dovremmo evitare di creare gli oggetti 'costosi' tutti in un sol colpo all'apertura del documento!
8.1.2.2.2. anche perche' non tutti questi oggetti saranno visibili nel documento allo stesso tempo
8.1.2.3. Potrei allora creare on-demand gli oggetti "costosi"
8.1.2.3.1. ovvero creare gli oggetti grafici solo quando diventano effettivamente visibili nell'editor
8.1.2.3.2. questo pero' senza complicare la vita delle altre funzionalita' dell'editor (formattazione, rendering)
8.1.2.4. Soluzione
8.1.2.4.1. usare un altro oggetto, un proxy della classe Image, che agisca come un sostituto dell'immagine vera
8.1.2.4.2. Untitled
9. Applicabilita'
9.1. Il Proxy e' utile in tutti i casi in cui e' necessaria una gestione piu' sofisticata dell'accesso ad un oggetto che non sia la semplice e diretta invocazione dei suoi metodi
9.2. Remote Proxy
9.2.1. rappresentazione locale di un oggetto che risiede in un differente "spazio di indirizzi"
9.2.1.1. ovvero l'oggetto reale e' remoto rispetto al client del suo proxy
9.2.1.2. aka Ambassador
9.3. Virtual Proxy
9.3.1. rappresentazione virtuale di un oggetto reale, il quale e' creato realmente solo se e' necessario accedervi
9.3.2. usato per la creazione on demand di oggetti 'costosi' da istanziare
9.3.2.1. esempio dell'ImageProxy
9.3.2.2. lazy instantiation
9.4. Protection Proxy
9.4.1. controlla l'accesso all'oggetto originale
9.4.2. serve per implementare politiche di accesso all'oggetto in base ai diritti del chiamante
9.5. Smart Reference
9.5.1. offre dei generici servizi "a valore aggiunto" rispetto ad un semplice accesso diretto all'oggetto
9.5.1.1. contare il numero di reference all'oggetto reale, per poterlo rimuovere quando nessuno lo referenzia piu'
9.5.1.2. caricare un oggetto persistente in memoria la prima volta che e' realmente acceduto
9.5.1.3. bloccare l'accesso all'oggetto reale (locking) in modo da garantire che solo un oggetto alla volta lo possa modificare
9.6. Copy-on-write Proxy
9.6.1. il proxy e' usato per postporre la copiatura di un oggetto fino a quando non e' strettamente necessario, ovvero fino a quando non viene modificato
9.6.1.1. si tiene il conto dei reference al RealSubject
9.6.1.2. quando il client richiede una copia del RealSubject, viene semplicemente incrementato il reference counter
9.6.1.3. solo quando il client richiede un'operazione di modifica sull'oggetto, questi viene realmente copiato e restituito al client
9.6.1.3.1. e il reference count viene decrementato
9.6.1.4. quando il reference count arriva a zero, si cancella l'oggetto reale
9.6.2. consente di ridurre il costo di copia di oggetti molto 'pesanti'