Design pattern

Nell'ingegneria del software, un design pattern può essere definito "una soluzione progettuale generale a un problema ricorrente". Esso non è una libreria o un componente di software riusabile, quanto una descrizione o un modello da applicare per risolvere un problema che può presentarsi in diverse situazioni durante la progettazione e lo sviluppo del software.

La differenza tra un algoritmo e un design pattern è che il primo risolve problemi computazionali, mentre il secondo è legato agli aspetti progettuali del software.

Storia

Il termine fu inizialmente introdotto in architettura in un celebre saggio di Christopher Alexander; in seguito, proprio l'opera di Alexander ispirò la nascita di un settore dell'ingegneria del software dedicato all'applicazione del concetto di design pattern alle architetture software, soprattutto object-oriented. Oggi, l'espressione design pattern viene usata principalmente con riferimento a questo particolare contesto.

Il tema dei pattern viene oggi considerato una delle linee principali di sviluppo dell'ingegneria del software object-oriented. Esso trova applicazioni in tutta una serie di contesti di grande interesse per l'industria del software, dallo sviluppo di software basato su componenti, ai sistemi aperti, ai framework e così via. La maggior parte dei linguaggi di programmazione moderni, e di tecnologie correlate, sono stati progettati (o modificati) tenendo conto anche dell'obiettivo di essere coerenti con questo approccio emergente allo sviluppo del software.

La nascita del "movimento" dei pattern in informatica si deve al celebre libro Design Patterns: Elementi per il riuso di software ad oggetti di Erich Gamma, Richard Helm, Ralph Johnson e John Vlissides (1995). Grazie al successo di quest'opera, i suoi quattro autori divennero nomi talmente citati che la comunità scientifica iniziò, per brevità, a identificarli collettivamente con un nomignolo: la "banda dei quattro" (Gang of Four o Gof).

Struttura di un pattern

Un design pattern è costituito da:

il nome, costituito da una o due parole che siano il più possibile rappresentative del pattern stesso;
il problema, ovvero la descrizione della situazione alla quale si può applicare il pattern. Può comprendere la descrizione di classi o di problemi di progettazione specifici, come anche una lista di condizioni perché sia necessario l'utilizzo del pattern;
la soluzione, che descrive gli elementi costitutivi del progetto con le relazioni e relative implicazioni, senza però addentrarsi in una specifica implementazione. Il concetto è di presentare un problema astratto e la relativa configurazione di elementi adatta a risolverlo;
le conseguenze, i risultati e i vincoli che derivano dall'applicazione del pattern. Sono fondamentali in quanto possono essere l'ago della bilancia nella scelta dei pattern: le conseguenze comprendono considerazioni di tempo e di spazio, possono descrivere implicazioni del pattern con alcuni linguaggi di programmazione e l'impatto con il resto del progetto.

L'uso di pattern nella descrizione di altri pattern dà origine ai cosiddetti linguaggi di pattern.

Utilizzo

Template:Sectstub

Critiche

Template:Sectstub

Classificazione dei design pattern

I design pattern possono essere classificati con diversi criteri, i più comuni dei quali sono quelli che evidenziano il tipo di problema che si cerca di risolvere. Il tipo di problema può essere legato ad uno specifico dominio progettuale (telecomunicazioni, reti, software...) oppure, più comunemente, al problema progettuale in senso più ampio (ad esempio creazione, comportamento, navigazione di oggetti o strutture dati).

Nel loro libro la "banda dei quattro" identificò 23 tipi di design pattern, suddivisi in 3 categorie: strutturali, creazionali e comportamentali.

Pattern Creazionali

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.

L'Abstract factory fornisce un'interfaccia per creare famiglie di oggetti connessi o dipendenti tra loro, in modo che non ci sia necessità da parte degli utilizzatori di specificare i nomi delle classi concrete all'interno del proprio codice.
Anonymous subroutine objects
Il Builder separa la costruzione di un oggetto complesso dalla sua rappresentazione, in modo che il processo di costruzione stesso possa creare diverse rappresentazioni.
Il Factory method fornisce un'interfaccia per creare un oggetto, ma lascia che le sottoclassi decidano quale oggetto istanziare.
La Lazy initialization è la tattica di instanziare un oggetto solo nel momento in cui deve essere usato per la prima volta. E' utilizzato spesso insieme al pattern factory method.
Il Prototype permette di creare nuovi oggetti clonando un'oggetto iniziale, o prototipo.
Singleton, il cui scopo è assicurare che di una classe possa essere creata una sola istanza.

Pattern Strutturali

I pattern strutturali consentono di riutilizzare degli oggetti esistenti fornendo agli utilizzatori un'interfaccia più adatta alle loro esigenze.

L'Adapter converte l'interfaccia di una classe in una interfaccia diversa
Bridge
Il Composite, utilizzato per dare la possibilità all'utilizzatore di manipolare gli oggetti in modo uniforme, organizza gli oggetti in una struttura ad albero.
Container
Il design pattern Decorator consente di aggiungere metodi a classi esistenti durante il run-time, permettendo una maggior flessibilità nell'aggiungere delle funzionalità agli oggetti.
Extensibility
Il Facade permette, attraverso un'interfaccia più semplice, l'accesso a sottosistemi che espongono interfaccie complesse e diverse tra loro.
Flyweight, che permette di separare la parte variabile di una classe dalla parte che può essere riutilizzata.
Proxy
Pipes and filters
Private class data

Pattern Comportamentali

I pattern comportamentali forniscono soluzione alle più comuni tipologie di interazione tra gli oggetti.

Chain of Responsibility
Il Command permette di isolare la porzione di codice che effettua un'azione dal codice che ne richiede l'esecuzione.
Event Listener
Hierarchical Visitor
Interpreter
L'Iterator risolve diversi problemi connessi all'accesso e alla navigazione attraverso gli elementi di una struttura dati, senza esporre i dettagli dell'implementazione e della struttura interna del contenitore.
Mediator
Il design pattern Memento è l'operazione di estrarre lo stato interno di un oggetto, senza violarne l’incapsulazione, e memorizzarlo per poterlo ripristinare in un momento successivo.
L'Observer definisce una dipendenza uno a molti fra oggetti diversi, in maniera tale che se un oggetto cambia il suo stato, tutti gli oggetti dipendenti vengono notificati del cambiamento avvenuto e possono aggiornarsi.
Single-serving Visitor
State
Il design pattern Strategy è utile in quelle situazioni dove è necessario modificare dinamicamente gli algoritmi utilizzati da un'applicazione.
Il Template method permette di definire la struttura di un algoritmo lasciando alle sottoclassi il compito di implementarne alcuni passi come preferiscono.
Il Visitor permette di separare un algoritmo dalla struttura di oggetti composti a cui è applicato, in modo da poter aggiungere nuovi comportamenti senza dover modificare la struttura stessa.

Pattern Architetturali

I pattern architetturali esprimono delle soluzioni adeguate alle fondamentali strutture o schemi di un sistema software.

Pattern di metodologia

Make it run, make it right, make it fast, make it small

Voci correlate

Anti-pattern
Framework orientato agli oggetti

Bibliografia

Gamma, E., Helm, R., Johnson, R. e Vlissides, J., Design Patterns: elementi per il riuso di software a oggetti, Addison Wesley, 1995, ISBN 887192150X
- Originale: Design Patterns: Elements of Reusable Object-Oriented Software, Addison Wesley, 1995, ISBN 0201633612
Eckel, B., Thinking in Patterns with Java, MindView (draft)