Vai alla Home Page About me Courseware Federica Living Library Federica Federica Podstudio Virtual Campus 3D Le Miniguide all'orientamento Gli eBook di Federica La Corte in Rete
 
 
Il Corso Le lezioni del Corso La Cattedra
 
Materiali di approfondimento Risorse Web Il Podcast di questa lezione

Stefano Russo » 12.Design Patterns


Introduzione

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.

Christopher Alexander

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:

  • Town patterns: Ring roads (circonvallazioni), night life, and row houses (case a schiera);
  • Building patterns: Roof garden, indoor sunlight, …

Tipi di Pattern

I pattern sono applicabili in ogni fase del ciclo di vita di un software: esistono

  • pattern di analisi;
  • pattern architetturali;
  • pattern di progettazione (design);
  • pattern di codifica.

Vantaggi dei pattern

Riuso della conoscenza/esperienza di progettazione

  • Raramente i problemi sono nuovi e unici.
  • I pattern forniscono indicazioni su “dove cercare soluzioni ai problemi”.

Stabiliscono una terminologia comune e condivisa

  • Es.: è facile dire “Qui ci serve un Façade”.

Forniscono una prospettiva di alto livello

  • Liberano dal dover gestire troppo presto i dettagli della progettazione

I pattern sono un “riferimento progettuale” (design reference).

Archetipi architetturali o pattern architetturali

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).

Pattern di progettazione

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.

Design Patterns

Generalmente i pattern di design sono catalogati e descritti utilizzando pochi elementi essenziali:

  • nome: descrive in maniera simbolica il problema di progettazione e le sue soluzioni;
  • problema: descrive quando applicare il pattern. Può descrivere problemi di progettazione specifici o anche strutture di classi o di oggetti sintomo di progettazione non flessibile;
  • soluzione: descrive gli elementi (oggetti, classi e idiomi) che costituiscono il progetto, le loro relazioni, le responsabilità e le collaborazioni. La soluzione è la descrizione astratta di un problema di progettazione e del modo in cui una configurazione di elementi (classi e oggetti, nel nostro caso), può risolverlo, ma non descrive una particolare progettazione o implementazione;
  • conseguenze: sono i risultati e i vincoli che si ottengono applicando il pattern, utili per valutare soluzioni alternative, capire e stimare i benefici derivanti dall’applicazione del pattern.

Un po’ di storia …

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.

The Gang of Four

Gamma, Helm, Johnson, Vlissides at OOPSLA 1994

Gamma, Helm, Johnson, Vlissides at OOPSLA 1994


Evoluzione dei Design Patterns


Catalogo dei Design Patterns

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.

Classificazione

I design pattern possono essere classificati in base a due criteri.
1. Scopo (purpose), che riflette cosa fa il pattern:

  • creational: astraggono il processo di creazione (instanziazione) di oggetti;
  • structural: trattano la composizione delle classi o oggetti per formare strutture più complesse;
  • behavioral: si occupano del modo (algoritmi) in cui classi o oggetti interagiscono reciprocamente e distribuiscono fra loro le responsabilità;

2. Ambito (scope), specifica se il pattern è relativo a classi o ad oggetti:

  • class: trattano la relazioni statiche, determinate a tempo di compilazione, tra classi e sottoclassi;
  • object: trattano relazioni dinamiche, che variano a tempo di esecuzione, tra oggetti.

Classificazione

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.

Classificazione


I materiali di supporto della lezione

E. Gamma, R. Helm, R. Johnson, J.M. Vlissides

“Design Patterns: Elements of Reusable Object-Oriented Software”,

Addison Wesley Professional Computing Series.

  • Contenuti protetti da Creative Commons
  • Feed RSS
  • Condividi su FriendFeed
  • Condividi su Facebook
  • Segnala su Twitter
  • Condividi su LinkedIn
Progetto "Campus Virtuale" dell'Università degli Studi di Napoli Federico II, realizzato con il cofinanziamento dell'Unione europea. Asse V - Società dell'informazione - Obiettivo Operativo 5.1 e-Government ed e-Inclusion