Modelli strutturali

2.1 Adattatore

Adapter (Adapter) è un modello di progettazione strutturale progettato per organizzare l'uso delle funzioni di un oggetto che non è disponibile per la modifica tramite un'interfaccia appositamente creata.

La definizione ufficiale è un po' complicata, ma se la descrivi con parole tue, un adattatore è un modello di progettazione che consente a oggetti con interfacce incompatibili di lavorare insieme .

Utilizzato per organizzare l'utilizzo delle funzioni di un oggetto che non è disponibile per la modifica tramite un'interfaccia appositamente creata. Viene creata una classe aggiuntiva che ha l'interfaccia richiesta e questa classe a sua volta chiama i metodi dell'oggetto desiderato (che non ha l'interfaccia richiesta).

Importante! Se nel codice incontri il suffisso Adapter per una classe, allora hai tutto il diritto di considerare che questa classe funge da adattatore ed è associata a un gruppo di classi che funzionano secondo lo schema sopra descritto.

Viene utilizzato nei casi in cui il sistema supporta i dati e il comportamento richiesti, ma ha un'interfaccia inappropriata. L'uso più comune del pattern Adapter è quando si desidera creare una classe che erediti da una classe astratta nuova o esistente.

Punti di forza:

• Il passaggio all'utilizzo di altre classi esterne non richiede la rielaborazione del sistema stesso, è sufficiente implementare un'altra classe Adapter.
• Indipendenza dall'implementazione di classi esterne (classi da librerie di cui non possiamo modificare il codice). Il tuo programma diventa indipendente dall'interfaccia delle classi esterne.

2.2 Decoratori

Decorator è un modello di progettazione strutturale per l'associazione dinamica di comportamenti aggiuntivi a un oggetto. Il modello Decorator fornisce un'alternativa buona e flessibile alla pratica della sottoclasse per estendere la funzionalità.

Utilizzato per connettere dinamicamente obblighi aggiuntivi a un oggetto.

Molti di voi chiederanno: come potete dinamicamente (mentre il programma è in esecuzione) aggiungere un nuovo comportamento a un oggetto? Un oggetto può essere assemblato da pezzi, cioè piccoli oggetti. Ricordi le catene di filtri nei servlet? O l'API Stream quando hai scritto una query usando filter(), map(), list()?

IntStream.of(50, 60, 70, 80, 90).filter(x -> x < 90).map(x -> x + 10).limit(3).forEach(System.out::print);

Punti di forza del motivo Decorator:

• Non è necessario creare sottoclassi per estendere la funzionalità di un oggetto.
• La capacità di connettere dinamicamente nuove funzionalità ovunque: prima o dopo la funzionalità principale dell'oggetto ConcreteComponent.

2.3 Deleghe

Il proxy è un modello di progettazione strutturale che fornisce un oggetto che controlla l'accesso a un altro oggetto, intercettando e trasmettendo tutte le sue chiamate.

Il modello Proxy fornisce un oggetto sostitutivo al posto dell'oggetto reale. Questo oggetto controlla l'accesso all'oggetto originale. Usato molto spesso.

Ricordi come abbiamo usato il framework Mockito e intercettato una chiamata a un oggetto reale usando il metodo Mockito.spy() o l'annotazione @Spy? Fu allora che fu creato uno speciale oggetto Proxy, attraverso il quale passavano tutte le chiamate all'oggetto originale.

E poi potremmo gestire queste chiamate aggiungendo regole all'oggetto. Esatto: l'oggetto originale non cambia e lavorare con esso diventa molto più flessibile. È particolarmente utile quando non chiamiamo l'oggetto proxy dal nostro codice, ma lo passiamo da qualche parte. Controllando così la comunicazione di due oggetti indipendenti da noi.

Tipologie di deleghe per scopo:

• Logging proxy : registra tutte le chiamate all'“Oggetto” con i relativi parametri.
• Proxy remoto (proxy remoti): fornisce la comunicazione con il "Soggetto", che si trova in uno spazio di indirizzi diverso o su una macchina remota. Può anche essere responsabile della codifica della richiesta e dei suoi argomenti e dell'invio della richiesta codificata al vero "Soggetto".
• Virtual proxy (proxy virtuali): assicura che il vero "Soggetto" venga creato solo quando è realmente necessario. Può anche memorizzare nella cache alcune delle informazioni sul vero "Soggetto" per ritardarne la creazione.
• Copy-on-write : fornisce una copia del "soggetto" quando il client esegue determinate azioni (un caso speciale del "proxy virtuale").
• Proxy di protezione : possono verificare se il chiamante dispone delle autorizzazioni necessarie per effettuare la richiesta.
• Caching Proxy : fornisce l'archiviazione temporanea dei risultati di calcolo prima di servirli a più client che possono condividere i risultati.
• Screening Proxy: Protegge il "Soggetto" da client pericolosi (o viceversa).
• Proxy di sincronizzazione : esegue il controllo di accesso sincronizzato al "Soggetto" in un ambiente asincrono multi-thread.
• Collegamento "intelligente" (proxy di riferimento intelligente): esegue azioni aggiuntive quando viene creato un collegamento all'"Oggetto", ad esempio calcola il numero di collegamenti attivi all'"Oggetto".

2.4 Ponte

Il modello Bridge è un modello di progettazione strutturale utilizzato per "separare l'astrazione e l'implementazione in modo che possano cambiare indipendentemente".

Il modello bridge utilizza l'incapsulamento, l'aggregazione e può utilizzare l'ereditarietà per condividere la responsabilità tra le classi.

Quando l'astrazione e l'implementazione sono separate, possono cambiare indipendentemente. In altre parole, quando implementato tramite il modello bridge, la modifica della struttura dell'interfaccia non interferisce con la modifica della struttura dell'implementazione.

Considera una tale astrazione come una figura. Esistono molti tipi di forme, ciascuna con proprietà e metodi propri. Tuttavia, c'è qualcosa che accomuna tutte le figure. Ad esempio, ogni forma deve essere in grado di disegnare se stessa, ridimensionarsi e così via.

Allo stesso tempo, la grafica del disegno può variare a seconda del tipo di sistema operativo o della libreria grafica. Le forme dovrebbero essere in grado di disegnare se stesse in vari ambienti grafici. Ma non è pratico implementare tutti i metodi di disegno in ogni forma o modificare la forma ogni volta che cambia il metodo di disegno.

In questo caso, il pattern bridge aiuta, permettendoti di creare nuove classi che implementeranno il disegno in vari ambienti grafici. Usando questo approccio, è molto facile aggiungere nuove forme e modi per disegnarle.

La connessione rappresentata dalla freccia nei diagrammi può avere 2 significati: a) “un tipo”, secondo il principio di sostituzione di Liskov, eb) una delle possibili implementazioni dell'astrazione. I linguaggi in genere usano l'ereditarietà per implementare sia a) che b), che tende a gonfiare le gerarchie di classi.

Il bridge serve proprio a risolvere questo problema: gli oggetti vengono creati a coppie da un oggetto di una classe della gerarchia A e della gerarchia B, l'ereditarietà all'interno della gerarchia A ha il significato di “varietà” secondo Liskov, e per il concetto di “implementazione di astrazione” viene utilizzato un collegamento dall'oggetto A al suo oggetto accoppiato B.

2.5 Facciata

Il Facade pattern è un pattern di progettazione strutturale che nasconde la complessità di un sistema riducendo tutte le possibili chiamate esterne a un singolo oggetto che le delega agli oggetti appropriati nel sistema.

Come fornire un'interfaccia unificata con una serie di implementazioni o interfacce disparate, ad esempio, a un sottosistema, se l'accoppiamento forte a quel sottosistema non è desiderabile o l'implementazione del sottosistema potrebbe cambiare?

Definire un punto di interazione con il sottosistema: un oggetto di facciata che fornisce un'interfaccia comune con il sottosistema e assegnargli la responsabilità di interagire con i suoi componenti. Una facciata è un oggetto esterno che fornisce un singolo punto di ingresso per i servizi del sottosistema.

L'implementazione di altri componenti del sottosistema è privata e non visibile ai componenti esterni. L'oggetto Facade fornisce un'implementazione del modello GRASP Resistente ai cambiamenti in termini di protezione contro i cambiamenti nell'implementazione del sottosistema.

Importante! Questo modello viene utilizzato quando vogliamo nascondere completamente un gruppo di oggetti e passare tutta la comunicazione con loro attraverso il nostro oggetto. Se vuoi solo fornire un certo controllo sul processo di comunicazione degli oggetti e non necessariamente nasconderli, allora è meglio usare il modello Proxy.