Create your own awesome maps

Even on the go

with our free apps for iPhone, iPad and Android

Get Started

Already have an account?
Log In

Proxy Pattern by Mind Map: Proxy Pattern
0.0 stars - 0 reviews range from 0 to 5

Proxy Pattern

Intento

Fornire un surrogato di un altro oggetto, per poter controllare l'accesso a quest'ultimo

Introdurre un ulteriore livello di indirezione, per offrire un accesso controllato/distribuito/intelligente

fa parte degli Structural Patterns

Motivazioni

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

perche' le operazioni di costruzione e inizializzazione di un oggetto possono essere molto costose e quindi conviene farle solo quando sono realmente necessarie, Approccio lazy

Esempio dell'editor di documenti, L'editor consente di inserire nei documenti degli oggetti grafici, per esempio delle grosse immagini, tali oggetti grafici possono essere costosi da creare, Aprire un documento dovrebbe pero' essere un'operazione veloce, percio' dovremmo evitare di creare gli oggetti 'costosi' tutti in un sol colpo all'apertura del documento!, anche perche' non tutti questi oggetti saranno visibili nel documento allo stesso tempo, Potrei allora creare on-demand gli oggetti "costosi", ovvero creare gli oggetti grafici solo quando diventano effettivamente visibili nell'editor, questo pero' senza complicare la vita delle altre funzionalita' dell'editor (formattazione, rendering), Soluzione, usare un altro oggetto, un proxy della classe Image, che agisca come un sostituto dell'immagine vera, che ritardi pero' la creazione della vera immagine il piu' possibile (es: solo quando l'editor manda il messaggio draw() all'immagine), Untitled

Applicabilita'

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

Remote Proxy

rappresentazione locale di un oggetto che risiede in un differente "spazio di indirizzi", ovvero l'oggetto reale e' remoto rispetto al client del suo proxy, aka Ambassador

Virtual Proxy

rappresentazione virtuale di un oggetto reale, il quale e' creato realmente solo se e' necessario accedervi

usato per la creazione on demand di oggetti 'costosi' da istanziare, esempio dell'ImageProxy, lazy instantiation

Protection Proxy

controlla l'accesso all'oggetto originale

serve per implementare politiche di accesso all'oggetto in base ai diritti del chiamante

Smart Reference

offre dei generici servizi "a valore aggiunto" rispetto ad un semplice accesso diretto all'oggetto, contare il numero di reference all'oggetto reale, per poterlo rimuovere quando nessuno lo referenzia piu', caricare un oggetto persistente in memoria la prima volta che e' realmente acceduto, bloccare l'accesso all'oggetto reale (locking) in modo da garantire che solo un oggetto alla volta lo possa modificare

Copy-on-write Proxy

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, si tiene il conto dei reference al RealSubject, quando il client richiede una copia del RealSubject, viene semplicemente incrementato il reference counter, solo quando il client richiede un'operazione di modifica sull'oggetto, questi viene realmente copiato e restituito al client, e il reference count viene decrementato, quando il reference count arriva a zero, si cancella l'oggetto reale

consente di ridurre il costo di copia di oggetti molto 'pesanti'

Struttura

Proxy

mantiene un reference che gli consente di accedere all'oggetto reale

aderisce all'interfaccia del Subject, in modo da poter essere usato al posto del RealSubject

controlla l'accesso all'oggetto reale, puo' avere la responsabilita' di crearlo e cancellarlo

altre responsabilita' dipendono dal tipo di proxy, il remote proxy e' responsabile dell'encoding del messaggio e dei suoi parametri e per il loro invio all'oggetto reale, che e' remoto, 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, es: l'ImageProxy si conserva la dimensione di una RealImage, il protection proxy e' responsabile di controllare se il chiamante ha i diritti necessari per invocare il messaggio sull'oggetto reale

Subject

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

RealSubject

definisce l'oggetto reale, il cui accesso e' mediato dal Proxy

Conseguenze

il proxy introduce un livello di indirezione nell'accesso ad un oggetto

questa indirezione puo' essere usata per diversi scopi, un remote proxy nasconde il fatto che l'oggetto e' remoto, un virtual proxy consente di realizzare ottimizzazioni come la creazione on demand dell'oggetto reale, protection proxy e smart reference consentono di realizzare servizi aggiuntivi quando si accede all'oggetto reale

Implementazione

E' possibile implementare il proxy pattern sfruttando le feature del linguaggio usato

in C++ si puo' fare l'overloading dell'operatore di accesso ai membri, ->, utile magari per realizzare smart reference proxy, non va bene pero' per tutti i tipi di proxy perche' non consente di distinguere tra metodi invocati

in Smalltalk si puo' usare doesNotUnderstand: per rigirare automaticamente le richieste all'oggetto reale, Smalltalk invoca il metodo doesNotUnderstand: aMessage quando un client manda un messaggio ad un receiver che non ha un metodo corrispondente, il proxy puo' allora ridefinire doesNotUnderstand in modo che il messaggio sia girato al suo oggetto reale, una cosa simile si puo' fare anche in Ruby

in Java si possono usare le API del Dynamic Proxy

In alcuni casi il proxy non deve conoscere il tipo esatto dell'oggetto da lui puntato

in questi casi il proxy puo' riferirsi al subject attraverso una interfaccia astratta, e quindi non e' necessario creare un proxy per ogni tipo concreto di RealSubject, questo approccio non va bene pero' nei casi in cui il proxy deve poter istanziare il RealSubject (virtual proxy), e quindi deve conoscere il suo tipo esatto

il Proxy deve avere un qualche riferimento indiretto ma univoco al RealSubject prima che sia istanziato, in modo da potervi accedere quando serve

Nell'esempio di Virtual Proxy del GOF, il reference all'Image è attraverso il nome del file dove l'immagine è salvata

Il Remote Proxy potrebbe puntare al RealSubject remoto attraverso un URI

Dubbi e issues

Nel sample code in C++ del GOF il client sa di usare un proxy, mentre non sempre e' cosi'

Pattern correlati

Adapter

fornisce una interfaccia diversa al RealSubject incapsulato

Decorator

simile struttura

diverso scopo, nel Decorator si vuole aggiungere comportamento all'oggetto incapsulato, nel Proxy si controlla l'accesso all'oggetto incapsulato

Facade

Reference

http://www.mip.sdu.dk/~bnj/designpatterns/hires/pat4g.htm

http://c2.com/cgi/wiki?ProxyPattern

http://home.earthlink.net/~huston2/dp/proxy.html

http://wiki.cs.uiuc.edu/patternStories/ProxyPattern

http://wiki.java.net/bin/view/Javapedia/ProxyPattern

http://wiki.ugidotnet.org/default.aspx/UGIdotNETWiki/PatternProxy.html