DEFINIZIONE GENERALE E TIPI DI PATTERNS

Il pattern si definisce come una soluzione architetturale che può risolvere problemi in contesti eterogenei.
C'è stato un gruppo di 4 persone, la cosiddetta GOF(Gang of Four) che ha creato 23 pattern in base a
differenti contesti e in base alla circostanza d'uso.
3 sono i tipi di Pattern fondamentali:
 Creational Patterns-Pattern creazionali: propongono soluzioni per creare oggetti
 Structural Patterns-Pattern strutturali: propongono soluzioni per la composizione strutturale di
classi e oggetti
 Behavioral Patterns-Pattern comportamentali: propongono soluzioni per gestire il modo in cui
vengono suddivise le responsabilità delle classi e degli oggetti

DEFINIZIONE DETTAGLIATA CREATIONAL PATTERNS

I pattern creazionali nascondono i costruttori delle classi e mettono dei metodi al loro posto creando
un'interfaccia: in questo modo si possono utilizzare oggetti senza sapere come sono implementati

Nomi dei Creational Patterns:

-Singleton(singoletto):
 Scopo: Assicura che una classe abbia una sola istanza e fornisce un punto globale di accesso ad essa
 Motivazione: per alcune classi è importante avere una sola istanza
 Applicabilità: deve esistere solo un’istanza della classe e deve essere accessibile da un punto noto.
L’unica istanza deve essere estesa e i client devono essere capaci di usare un’istanza estesa senza
modificare il loro codice

-Factory Method(metodo fabbrica):--->detto anche Virtual Constructor

 Scopo: Definire un’interfaccia per creare un oggetto ma lasciare la scelta del suo tipo alla
sottoclasse essendo la creazione differita a runtime
 Motivazione: I Framework usano classi astratte per definire e mantenere le relazioni tra oggetti.
e.g., framework per applicazioni che presenta diversi documenti all’utente.
e.g., in hotel, Stanza factory, Chiamata telefonica factory
 Applicabilità: una classe non può anticipare la classe di oggetti che deve creare. Una classe vuole
che le sottoclassi specificano gli oggetti da creare. Le classi delegano le responsabilità ad una delle
diverse sottoclassi “helper”

-Abstract factory(fabbrica astratta): ---->conosciuto anche come Kit

 Scopo: Disporre di un’interfaccia per creare una famiglia di oggetti connessi o dipendenti senza
specificare le loro classi concrete
 Motivazione: Modularizzazione, aggiungere codice a classi esistenti in modo da incapsulare
informazioni più generali. e.g., gestore telefonico, ogni numero è identificato dall’area e dal
paese. Aggiungere numeri di altri paesi potrebbe essere complicato
 Applicabilità: un sistema indipendente dalla creazione, composizione e rappresentazione dei suoi
prodotti. Un sistema configurato con molte famiglie di prodotti. Creare una libreria di prodotti e
vogliamo conoscere solo le loro interfacce e non l’implementazione

PIERLUIGI LIPARDI—UNIVERSITA’ PARTHENOPE 1

-Factory Pattern:
 Scopo: Creare oggetti senza esporre la logica di instanziazione al client. Creazione di oggetti
attraverso un’interfaccia comune.
 Motivazione: E’ probabilmente il più usato pattern nei moderni linguaggi di programmazione, ad
esempio JDK, Spring e Struts lo usano
 Applicabilità: Ha differenti varianti e deriva dal Factory Method e Abstract Factory

-Builder(costruttore):
 Scopo: Separare la costruzione di un oggetto complesso dalla sua rappresentazione in modo tale
che lo stesso processo di costruzione può creare differenti rappresentazioni
 Motivazione: Un’applicazione potrebbe avere bisogno di un meccanismo per la costruzione di
oggetti complessi che è indipendente da quelli che compongono l’oggetto. Definisce un’istanza per
creare un oggetto ma dando la possibilità alle sottoclassi di decidere quali classi istanziare.
Riferimento ai nuovi oggetti creati attraverso un’interfaccia comune
 Applicabilità: Un algoritmo per creare un oggetto complesso deve rendere indipendenti le parti per
costruire l’oggetto e per il loro assemblaggio. Il processo di costruzione deve permettere differenti
rappresentazioni per gli oggetti costruiti. Si può usare per:
Casa automobilistica
può costruire auto, biciclette, motociclette e scooter
Builder diventa VehicleBuilder
Applicazione per gli esami studenti
lista e informazioni di esami
differenti utenti di login (admin e user)
Builder fornisce un’interfaccia che fornisce informazioni in base all’utente

-Prototype(prototipo):
 Scopo: Specifica il tipo di oggetti da creare usando un’istanza prototipale e creando nuovi oggetti
copiando questi oggetti
 Motivazione: Permette ad un oggetto di creare oggetti senza conoscere la loro classe o i dettagli
per crearli
 Applicabilità: sistema indipendente da come i suoi prodotti sono creati, composti e rappresentati.
Le classi da istanziare sono specificate a run-time per evitare di scrivere una gerarchia di classi.
E’ più conveniente copiare un’istanza esistente che crearne una nuova. Si usa per:
Game
un labirinto con diversi oggetti visuali
per generare diverse mappe del labirinto
Muri, porte, passaggi, stanze, …
diversi prototipi per i componenti
Vendite
analisi di dati da un database
per ogni analisi sugli stessi dati possiamo clonare le
informazioni estratte dal database

PIERLUIGI LIPARDI—UNIVERSITA’ PARTHENOPE 2

DEFINIZIONE DETTAGLIATA BEHAVIORAL PATTERNS
I Behavioral Patterns-Pattern comportamentali forniscono soluzione alle più comuni tipologie di interazione
tra gli oggetti

Tipi di Behavioral Patterns:

-Chain of Responsibility:
 Scopo: Consente di separare il mittente di una richiesta dal destinatario, in modo da consentire al
più ad un oggetto di gestire la richiesta. Gli oggetti destinatari vengono messi in “catena” e la
richiesta viene trasmessa fino a trovare un oggetto che la gestisca.
 Motivazione: CoR permette ad un oggetto di inviare un comando senza conoscere quale oggetto la
riceverà e la gestirà la richiesta è inviata da un oggetto all’altro nella catena
 Applicabilità: Il pattern CoR è usato quando non conosciamo a priori quale oggetto è in grado di
gestire una determinata richiesta. l’oggetto può essere sconosciuto staticamente. L'insieme degli
oggetti in grado di gestire richieste cambia dinamicamente a runtime. Si può usare per:
Sistema di approvazione di richieste di acquisto
invio richiesta ad un’autorità di omologazione acquisti
a seconda del valore, tale autorità può approvare la
richiesta o trasmettere alla prossima autorità della
catena
GUI
propagazione eventi GUI tra catene di oggetti
quando un evento viene generato (click del mouse)
deve essere trasmesso all’oggetto che lo ha generato
Sistema per gli ordini elettronici
Una azienda commerciale deve gestire le richieste di
credito dei clienti (customers)
Internamente l’azienda si organizza in diversi livelli di
Responsabilità:
- l livello (vendor) viene consentita l’approvazione di richieste fino a un importo
determinato
- livello superiore (sales manager)
altro importo massimo da gestire
- alto livello (client account manager)

-Command: ----->conosciuto come Action, Transaction

 Scopo: Incapsula una richiesta all’interno di un oggetto, consentendo così di parametrizzare i client
con richieste diverse, accodare o rintracciare le richieste, oppure supportare operazioni di
undo(disfare)
 Motivazione: Spesso si rende necessario richiedere dei compiti ad oggetti senza conoscere tutto
sulle operazioni richieste o il ricevente delle richieste. e.g., tool per l’interfaccia utente. Non è
possibile implementare le azioni specifiche (Button, Menu, …).
 Applicabilità: parametrizzare oggetti a seconda dell’azione che devono svolgere. Specificare o
aggiungere informazioni in una coda ed eseguire le richieste in diversi momenti nel tempo.
Sostegno ad azioni annullabili in grado di memorizzare lo stato e consentire di tornare a
quello stato. Strutturare il sistema in operazioni di alto livello che, sulla base operazioni primitive
disaccoppia l’oggetto che richiama l’azione dall’oggetto che esegue l’azione. E’ conosciuto anche
come produttore - consumatore design pattern. Si può usare anche per:
Officina riparazione auto

PIERLUIGI LIPARDI—UNIVERSITA’ PARTHENOPE 3

 autovetture con problemi diversi
reception prende informazioni e colloca la macchina in
una coda per la riparazione, le informazioni sull’ordine sono consegnate al
proprietario per effettuare il ritiro. Al turno corrispondente il meccanico ripara l’auto
-Interpreter:
 Scopo: Dato un linguaggio, definisce la rappresentazione per la sua grammatica insieme ad un
interprete che usa la rappresentazione per interpretare frasi del linguaggio
 Motivazione: In particolari tipi di problemi può essere utile esprimere istanze di un problema come
frasi di un linguaggio semplice
 e.g., pattern string matching, regular expressions
 Applicabilità: quando la grammatica è semplice, quando non abbiamo vincoli di efficienza.
Può essere applicato ad un’area limitata

-Iterator:
 Scopo: Fornisce un modo per accedere agli elementi di un oggetto aggregato nascondendo i
dettagli di implementazione.
 Motivazione: Un oggetto aggregato dovrebbe fornire un metodo per accedere agli elementi senza
esporre la struttura interna
 Applicabilità: accedere a contenuti di una collezione senza esporre la sua struttura interna.
Supportare più scorrimenti simultanei di una collezione. Fornire un’interfaccia uniforme per lo
scorrimento di collezioni differenti

-Mediator:
 Scopo: Definire un oggetto che incapsula il meccanismo di interazione di oggetti, consentendo il
loro disaccoppiamento in modo da variare facilmente le interazioni tra di loro.
 Motivazione: permettere di modificare agilmente le politiche di interazione, poiché le entità
coinvolte devono fare riferimento al loro interno solamente al mediatore
 Applicabilità: Un insieme di oggetti comunicano in un modo ben definito ma complesso. Le
interdipendenze non strutturate e difficili da capire. Il riuso di un oggetto è difficile perché si
riferisce e relaziona molti altri oggetti. Un comportamento distribuito tra diverse classi dovrebbe
essere customizzabile senza l’uso di molte sottoclassi. Per esempio si può usare per costruire una
chat

-Memento:
 Scopo: L’intento di questo modello è di catturare lo stato interno di un oggetto senza violare
incapsulamento e fornendo così un mezzo per ripristinare l’oggetto allo stato iniziale
quando necessario.
 Motivazione: A volte si rende necessaria l’acquisizione dello stato interno di un oggetto in un certo
istante e ripristinare successivamente l’oggetto a quello stato. Il processo è utile in caso di errori,
e.g., calcolatrice che mantiene la lista delle operazioni precedenti
 Applicabilità: viene utilizzato quando uno stato di un oggetto deve essere catturato in modo che
possa essere ripristinato a quello stato più tardi. In situazioni in cui il passaggio in modo esplicito
dello stato dell’oggetto violerebbe incapsulamento. Si può anche usare per gestione file

-Observer: ---->conosciuto come Publish-Subscribe

 Scopo: Definisce una dipendenza una a molti tra oggetti, tale che se un oggetto cambia stato, tutte
le sue dipendenze sono notificate e aggiornate automaticamente
 Motivazione: Un effetto del partizionamento di un sistema in una collezione di classi cooperanti è la
necessità di mantenere le consistenze tra gli oggetti. Le classi non devono essere fortemente
accoppiate perché riducono la loro riusabilità

PIERLUIGI LIPARDI—UNIVERSITA’ PARTHENOPE 4

  Applicabilità: quando un’astrazione ha due aspetti che dipendono l’uno dall’altro. L’incapsulamento
di questi aspetti in oggetti separati permette il loro riuso in modo indipendente. Quando il
cambiamento di un oggetto richiede il cambiamento di altri e non si conoscono quanti oggetti
hanno bisogno di essere cambiati. Si può usare nell’ambito comunicazione numeri

-State:---->conosciuto anche come Objects for States

 Scopo: Permette ad uno oggetto di cambiare il proprio comportamento quando cambia il suo stato
interno. L’oggetto sembrerà cambiare la sua classe.
 Motivazione: soluzione al problema di come rendere il comportamento dipendente dallo stato.
Consente ad un oggetto di cambiare il proprio comportamento a run-time in funzione dello stato in
cui si trova
 Applicabilità: il comportamento associato ad uno stato dipende solo da una classe. La logica che
implementa il cambiamento di stato viene implementata in una sola classe piuttosto che con
istruzioni condizionali nella classe che implementa il comportamento. Evita stati incoerenti

-Strategy: ---->conosciuto anche come Policy

 Scopo: Definire una famiglia di algoritmi, incapsularli e renderli intercambiabili. L’algoritmo cambia
indipendentemente dai client che lo usano.
 Motivazione: necessità di modificare dinamicamente gli algoritmi utilizzati da un’applicazione.
e.g., visite in una struttura ad albero, possibilità di selezionare a tempo di esecuzione una tra le
visite
 Applicabilità: classi correlate differiscono solo per il loro comportamento. Abbiamo bisogno di
varianti di un algoritmo. Un algoritmo usa dati che i client non dovrebbero conoscere.
Una classe definisce diversi comportamenti

-Template Method:
 Scopo: Definire lo scheletro di un algoritmo in un’operazione, rinviando alcuni passi alle sottoclassi
client. Consente alle sottoclassi di ridefinire alcuni passi senza cambiare la struttura dell’algoritmo.
 Motivazione: necessità di modificare dinamicamente gli algoritmi utilizzati da un’applicazione
e.g., visite in una struttura ad albero, possibilità di selezionare a tempo di esecuzione una tra le
visite
 Applicabilità: quando si vuole implementare la parte invariante di un algoritmo una volta sola e
lasciare che le sottoclassi implementino il comportamento che può variare. Quando il
comportamento comune di più classi può essere fattorizzato in una classe a parte per evitare di
scrivere più volte lo stesso codice. Per avere modo di controllare come le sottoclassi ereditano dalla
superclasse, facendo in modo che i metodi template chiamino dei metodi “gancio” (hook) e
impostarli come unici metodi sovrascrivibili

-Visitor:
 Scopo: Rappresentare un’operazione da eseguire sugli elementi di una struttura oggetto. Permette
di definire una nuova operazione senza cambiare le classi degli elementi su cui opera.
 Motivazione: separare un algoritmo dalla struttura di oggetti composti a cui è applicato.
Aggiungere nuove operazioni e comportamenti senza dover modificare la struttura stessa.
In collezioni contenere oggetti di tipo diverso
operazioni eseguite su tutti gli elementi di raccolta senza conoscere il tipo
 Applicabilità: una struttura di oggetti è costituita da molte classi con interfacce diverse ed è
necessario che l’algoritmo esegua su ogni oggetto un’operazione differente a seconda dalla
classe concreta dell’oggetto stesso. E’ necessario eseguire svariate operazioni indipendenti e
non relazionate tra loro sugli oggetti di una struttura composta, ma non si vuole sovraccaricare le
interfacce delle loro classi. Riunendo le operazioni correlate in ogni Visitor è possibile inserirle nei

PIERLUIGI LIPARDI—UNIVERSITA’ PARTHENOPE 5

 programmi solo dove necessario. Le classi che costituiscono la struttura composta sono raramente
suscettibili di modifica, ma è necessario aggiungere spesso operazioni sui rispettivi oggetti

DEFINIZIONE DETTAGLIATA STRUCTURAL PATTERNS

I Structural Patterns consentono di riutilizzare degli oggetti esistenti fornendo agli utilizzatori un’interfaccia
più adatta alle loro esigenze

Esempi di Structural Patterns:

-Adapter: --->conosciuto anche come Wrapper
 Scopo: Converte l’interfaccia di una classe in un’altra richiesta dai client. Permette alle classi di
collaborare sebbene esista un’incompatibilità di interfacce.
 Motivazione: fornire una soluzione astratta al problema dell’interoperabilità tra interfacce
differenti, e.g., in un software si devono utilizzare sistemi di supporto (come per esempio librerie)
la cui interfaccia non è perfettamente compatibile con quanto richiesto da applicazioni già esistenti
 Applicabilità: utilizzo di una classe esistente che presenti un’interfaccia diversa da quella
desiderata. Scrittura di una determinata classe senza poter conoscere a priori le altre classi con cui
dovrà operare

-Bridge: ----->conosciuto anche come Handle/Body

 Scopo: Separa un’astrazione dalla sua implementazione, in modo che entrambe possano variare
indipendentemente.
 Motivazione: Spesso un’astrazione deve avere diverse implementazioni:
gestione di database relazionali o file system
soluzione - ereditarietà
l’ereditarietà lega un’implementazione all’astrazione
 Applicabilità: necessità di evitare un collegamento permanente tra l’astrazione e
l’implementazione. Quando l’astrazione e l’implementazione hanno bisogno di cambiare
indipendentemente. Usando il pattern è possibile lasciare il codice del client inalterato senza la
necessità di ricompilarlo. Preferire la composizione all’eredità

-Composite:
 Scopo: Comporre oggetti una struttura ad albero per rappresentare gerarchie (whole-part). Il
pattern permette ai client di trattare oggetti singoli e composizioni di oggetti uniformi.
 Motivazione: applicazioni hanno bisogno di manipolare una collezione di oggetti primitivi o
composti. Se l’oggetto desiderato è una Leaf, la richiesta è processata direttamente. Se è una
Composite, viene rimandata ai figli cercando di svolgere le operazioni prima
 Applicabilità: quando i client dovrebbero ignorare la differenza tra oggetti composti e oggetti
singoli.
Scelta di rifattorizzazione:
durante lo sviluppo i programmatori scoprono che stanno usando più oggetti nello stesso modo e
spesso il codice per gestirli è molto simile

-Decorator:
 Scopo: Aggiunge responsabilità addizionali ad un oggetto dinamicamente. Fornisce un’alternativa
flessibile alla costruzione di sottoclassi per estendere delle funzionalità.
 Motivazione: consente di aggiungere durante il run-time nuove funzionalità ad oggetti già esistenti:
nuova classe decoratore che “avvolge” l’oggetto originale

PIERLUIGI LIPARDI—UNIVERSITA’ PARTHENOPE 6

 Valida alternativa all’uso dell’ereditarietà singola o multipla
 Applicabilità: quando vogliamo aggiungere comportamenti o stati ad oggetti individuali a run-time.
L’ereditarietà non è flessibile poiché è statica ed è applicata ad una intera classe

-Facade:
 Scopo: Fornisce un’interfaccia unificata ad un insieme di interfacce in un sottosistema. Definisce
un’interfaccia di alto livello che permette la facile gestione del sottosistema.
 Motivazione: permettere attraverso un’interfaccia più semplice, l’accesso a sottosistemi che
espongono interfacce complesse e molto diverse tra loro, nonché a blocchi di codice complessi
 Applicabilità: quando vogliamo fornire un’interfaccia semplice ad un sottosistema complesso.
Sdoppiare client e sottosistemi.
Definire un entry point per ogni sottosistema

-Flyweight:
 Scopo: Separare la parte variabile di una classe dalla parte che può essere riutilizzata, in modo tale
da condividere quest’ultima tra differenti istanze.
 Motivazione: uso della condivisione per supportare un grande numero di oggetti che hanno parti di
stato interno in comune e l’altra parte dello stato può cambiare
 Applicabilità: un’applicazione usa un grande numero di oggetti. I costi di memorizzazione sono alti.
Gruppi di oggetti possono essere rimpiazzati da un numero minore di oggetti condivisi

-Proxy:
 Scopo: Fornire un surrogato (o placehoder) per un altro oggetto per controllare l’accesso ad esso.
 Motivazione: classe che funziona come interfaccia per qualcos’altro:
connessione di rete, un grosso oggetto in memoria, un file e altre risorse che sono costose o
impossibili da duplicare
 Applicabilità:
Remote proxy
fornisce una rappresentazione locale per un oggetto in una
differenti spazio di indirizzi
Virtual Proxy
crea oggetti costosi su richiesta
Protection proxy
controlla l’accesso all’oggetto originale
Smart proxy
interpone azioni addizionali quando si fa accesso ad un oggetto:
conteggio del numero di referenze
caricamento dell’oggetto in memoria al primo riferimento
controllo che l’oggetto reale non sia accessibile

PIERLUIGI LIPARDI—UNIVERSITA’ PARTHENOPE 7