“A pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice“.
[Christopher Alexander, Sara Ishikawa, Murray Silverstein, Max Jacobson, Ingrid Fiksdahl-King, Shlomo Angel. A Pattern Language. Oxford University Press, New York, 1977.]
I Pattern sono soluzioni a problemi ricorrenti che si incontrano in applicazioni reali.
I Pattern spiegano come realizzare oggetti e le interazioni tra essi, costruendo codice riusabile.
L’architetto C. Alexander introdusse il concetto di pattern nel suo libro “The Timeless Way of Building”.
La sua nozione di pattern come best practice per problemi di progettazione comuni e ricorrenti è stata adottata dalla comunità software.
Alexander introdusse il concetto di linguaggio di pattern, come un insieme di schemi che complessivamente forniscono un vocabolario base per la progettazione all’interno di uno specifico contesto o dominio applicativo.
In “A Pattern Language”, Alexander introdusse uno specifico linguaggio di pattern per il dominio architettonico, con ad esempio sottolinguaggi per la progettazione urbanistica delle città (rivolto a chi fa pianificazione urbanististica) e edile (rivolto agli architetti).
Esempi di pattern definiti da Alexander sono:
Fonte Wikimedia Commons
I pattern sono applicabili in ogni fase del ciclo di vita di un software: esistono
Riuso della conoscenza/esperienza di progettazione
Stabiliscono una terminologia comune e condivisa
Forniscono una prospettiva di alto livello
I pattern sono un “riferimento progettuale” (design reference).
Il progetto di architetture software può essere guidato da altre architetture.
Una architettura astratta riusabile è chiamata “archetipo architetturale” o “stile architetturale”.
Su una scala più piccola, le “micro-architetture” riusabili sono dette “pattern di progettazione” (design patterns).
C. Alexander definisce un pattern come una tripla che esprime una relazione tra un problema, una soluzione, e un contesto:
Pattern = coppia (problema, soluzione) in un contesto
Nel campo dell’ingegneria del software, un pattern di progettazione (design pattern) è una soluzione comprovata a un problema tipico che sorge nello sviluppo software in uno specifico contesto.
Generalmente i pattern di design sono catalogati e descritti utilizzando pochi elementi essenziali:
Nel 1987 W. Cunningham e K. Beck lavoravano al linguaggio Smalltalk e individuarono alcuni pattern.
La nozione di pattern è stata resa popolare da Gamma, Helm, Johnson e Vlissides, che lavoravano alla definizione di framework di sviluppo (E++, Unidraw).
Essi divennero noti come la Banda dei Quattro (“Gang of four“, Go4).
I design patterns da essi definiti adoperano un approccio di documentazione uniforme.
La ricerca del pattern da utilizzare è semplificata dall’utilizzo di un catalogo di pattern: GoF, Design Patterns – Elements of Reusable Object-Oriented Software.
Il volume descrive 23 pattern in un formato consistente per semplificarne la ricerca e l’apprendimento.
Pattern name and classification; Intent;
Also Known As; Motivation;
Applicability; Structure;
Participantes; Collaborations;
Consequences; Implementation;
Sample Code; Known Uses;
Related Patterns.
I design pattern possono essere classificati in base a due criteri.
1. Scopo (purpose), che riflette cosa fa il pattern:
2. Ambito (scope), specifica se il pattern è relativo a classi o ad oggetti:
Nei design pattern creazionali relativi a classi, la creazione di oggetti è affidata a sottoclassi mentre nei design pattern relativi a oggetti tale responsabilità è affidata ad altri oggetti.
Nei pattern strutturali relativi a classi, la composizione di classi è realizzata attraverso l’ereditarietà, mentre i pattern strutturali relativi a oggetti descrivono come assemblare oggetti.
I pattern comportamentali relativi a classi utilizzano l’ereditarietà per descrivere algoritmi e controllo di flusso, mentre i pattern comportamentali relativi a oggetti descrivono come cooperano gli oggetti per eseguire un compito che non può essere portato a termine da un singolo oggetto.
2. La modellazione a oggetti e il linguaggio UML (richiami)
3. Generalità su Java e la programmazione ad oggetti
6. Regole di traduzione da UML a Java/C++
7. Programmazione multi-thread
8. Sincronizzazione tra thread
9. Programmazione client-server con socket TCP/IP (Java networkin...
10. Programmazione di applicazioni client-server: il Pattern Proxy...
12. Design Patterns
13. Pattern architetturali - Esempi
14. Design pattern creazionali. Esempi
15. Design pattern strutturali. Esempi
16. Introduzione alle tecnologie middleware
17. Modelli di middleware: RPC, MOM, TP, TS
E. Gamma, R. Helm, R. Johnson, J.M. Vlissides
“Design Patterns: Elements of Reusable Object-Oriented Software”,
Addison Wesley Professional Computing Series.