Design Pattern UML

Design pattern​: ​soluzione progettuale generale ad un problema ricorrente, di

comprovata efficacia, in un certo contesto.

Design pattern Strutturali​:​ ​affrontare problemi che riguardano la composizione di

classi e oggetti e consentire il riutilizzo degli oggetti esistenti fornendo agli
utilizzatori un’interfaccia più adatta.

● Adapter​: ​ha lo scopo di convertire l’interfaccia di una classe in un’altra.

● Decorator​: ​ha lo scopo di aggiungere e/o disattivare una funzionalità ad un

oggetto, staticamente o dinamicamente, senza influire sul comportamento
degli altri oggetti della classe.

1
 ● Facade​: ​fornisce un’interfaccia unificata semplice a un sottosistema di
interfacce complesso.

● Proxy​: ​fornisce un surrogato di un altro oggetto di cui si vuole controllare

l’accesso.

Design pattern Creazionali​:​ ​consentono di rendere il sistema indipendente da

come gli oggetti sono creati e rappresentati e dalle relazioni di composizione tra
essi.

● Singleton​: ​ha lo scopo di garantire che di una determinata classe venga

creata una ed una sola istanza, e di fornire un punto di accesso globale ad
essa.

2
 ● Builder​: ​separare la costruzione di un oggetto complesso dalla sua
rappresentazione.

● Abstract Factory​:​ fornisce un'interfaccia per creare famiglie di oggetti

correlati o dipendenti senza specificare le loro classi concrete.

Design pattern Comportamentali​:​ ​si riferiscono al modo in cui un oggetto svolge

la sua funzione e al modo in cui diversi oggetti collaborano tra loro.
● Command​: ​permette di incapsulare nell’oggetto command la porzione di
codice che effettua un’azione (eventualmente molto complessa) dal codice
che ne richiede l’esecuzione, cosicchè i client siano indipendenti dalle
richieste.

3
● Iterator​: ​fornisce l’accesso sequenziale agli elementi di un aggregato, senza
esporre l’implementazione dell’aggregato stesso.

● Observer​: ​in questo caso un oggetto, chiamato soggetto, mantiene una lista
dei sui dipendenti, chiamati osservati, e li notifica automaticamente di
qualsiasi cambiamento di stato, di solito chiamando uno dei loro metodi.

● Strategy​: ​consente di selezionare un algoritmo a runtime; invece di

implementare direttamente un singolo algoritmo, il client riceve a run-time
quale algoritmo utilizzare in base al compito da svolgere.

4
 ● Template method​: d​ efinisce lo scheletro di un algoritmo, lasciando
l’implementazione di alcuni passi alle sottoclassi, che forniscono il
comportamento concreto.

Design pattern Architetturali

● Dependency injection​: c​ onsente di separare il comportamento di una
componente dalla risoluzione delle sue dipendenze. Collegare due
componenti in modo esplicito ne aumenta l’accoppiamento ma le
dipendenze vanno minimizzate!
Per utilizzare questo pattern è sufficiente dichiarare le dipendenze che un
componente necessita, dette anche ​interface contracts​: quando il
componente verrà istanziato, un ​iniettore​ si prenderà carico di risolvere le
dipendenze.

Model-View Pattern​: ​nati per fornire interfacce utente (GUI) per lo stesso
modello. I dati devono poter essere modificati attraverso interazioni differenti con i
client e il supporto a diverse viste non deve influire sulle componenti che
forniscono le funzionalità base.

❖ Model-View Controller​: b​ asato sulla suddivisione dei compiti tra 3

componenti principali:
➢ Model​: ​modello dei dati e regole di accesso ad essi. Il ​Model​ notifica
alla view gli aggiornamenti del modello dati in modo che la view mostri
sempre dati aggiornati (​Observer pattern)​ .

5
 ➢ View​: ​rappresentazione grafica. Gestisce la logica di presentazione
verso i vari utenti: cattura l’input e delega al controller l’elaborazione.
➢ Controller:​ gestisce la reazione della UI agli input dell’utente.
Trasforma le interazioni dell’utente in azioni sui dati.
Due tipi di aggiornamenti:
Push model​: view costantemente aggiornata (​Observer pattern​)

6
 Pull model​: la view richiede aggiornamenti solo quanto è opportuno

❖ Model-View Presenter​: p ​ resenter ⇒ ​passive view​: è un man-in-the-middle

che osserva il modello e aggiorna la view (una sorta di interfaccia di
comunicazione).

❖ Model-View ViewModel​: ​astrae lo stato della view e il comportamento:

➢ Model​: ​modello dei dati.
➢ View​: ​non possiede più lo stato dell’applicazione, ma è responsabile
della definizione della struttura, cioè del layout di ciò che vede l’utente.
➢ ViewModel: ​intermediario tra la vista e il modello; è responsabile della
logica della vista.