Erich Gamma, Richard Helm, Ralph Johnson, John Vlisside; non sono una boyband, ma 4 persone che hanno introdotto un'innovazione significativa all'ingegneria del software. Sono Diego Purpo e insieme scopriremo i Design Pattern.
In ogni attività che abbia raggiunto il suo stadio di maturità è possibile identificare una serie di metodi replicabili, efficaci ed efficienti, utili al raggiungimento di determinati obiettivi legati all'attività stessa. È possibile astrarre questi metodi e creare dei modelli concettuali, in inglese "pattern".
I quattro di cui sopra, presto ribattezzati "Gang of Four", o più comunemente GoF, entrano nel mito nel 1995, quando fu pubblicata la loro opera Design Patterns - Elementi per il riuso di software ad oggetti.
L'idea di base è stata quella di evidenziare i modelli tipici e di più successo (patterns) utilizzati nella progettazione di software (design).
Il termine design pattern, precedentemente già associato all'architettura, entra a far parte del mondo informatico.
Possiamo definire un design pattern come una soluzione generale ad un problema di progettazione ricorrente, quindi non stiamo parlando di un pacchetto software o di una serie di librerie da installare e sfruttare. Il punto di vista è molto più alto rispetto al codice. Ogni pattern, infatti, presenta un modello, in termini di classi, interfacce, oggetti e relazioni, per la risoluzione di un dato "dilemma architetturale", in cui ci si possa imbattere in fase di progettazione e sviluppo.
Ogni pattern è descritto da 4 elementi: il nome, il problema, la soluzione, le conseguenze.
Il nome è costituito da una o due parole che siano il più possibile rappresentative del pattern
Il problema è una 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 descrive gli elementi costitutivi del progetto con le relazioni e relative implicazioni, senza però addentrarsi in una specifica implementazione. In generale, la soluzione è presentata anche grazie al supporto di diagrammi UML statici come un class diagram o dinamici come i sequence diagram.
Le conseguenze definiscono gli effetti negativi derivanti dall'uso di un dato pattern: considerazioni di tempo e spazio, vincoli con i linguaggi ed impatto su tutta l'architettura del software. Questo fattore influenza pesantemente la scelta del pattern da utilizzare.
I design pattern sono classificati secondo la tipologia di problema progettuale che mirano a risolvere. I primi 23 pattern, quelli identificati dal GoF, sono stati classificati in:
- Creazionali
- Strutturali
- Comportamentali
Nei pattern creazionali l'obiettivo è nascondere i costruttori, sostituendoli con interfacce e metodi. L'applicazione utilizzerà gli oggetti senza preoccuparsi della loro implementazione. Tipici esempi sono l'Abstract Factory, il Builder e il Factory method.
I pattern strutturali permettono di utilizzare classi ed oggetti già esistenti, creando dei "filtri" che ne permettano l'integrazione nella nuova applicazione. Esempi sono l'Adapter ed il Bridge.
I pattern comportamentali forniscono soluzioni ai più comuni problemi di interazione tra i vari oggetti di un sistema. Ricordiamo l'Observer lo State e lo Strategy.
Lo sviluppo dell'ingegneria del software ha permesso, inoltre, di identificare numerosi nuovi design pattern, oltre quelli descritti dalla Gang of Four, che affrontano anche ulteriori classi di problemi progettuali, sono nati quindi nuovi tipi di design pattern:
- architetturali, tra questi spicca l'ormai diffusissimo l'MVC
- pattern di metodologia
- pattern di concorrenza
Ma quali sono i veri vantaggi di progettare applicazioni anche in termini di design pattern?
Il progetto di un'applicazione deve rappresentare una certa realtà, e allo stesso tempo garantire la flessibilità necessaria ad accogliere le frequenti trasformazioni degli scenari iniziali.
Occorre, quindi:
- una buona astrazione nella gerarchia delle classi
- una buona definizione delle responsabilità
- una limitata dipendenza tra gli oggetti
- un alto grado di manutenibilità
I design pattern favoriscono il raggiungimento di questi obiettivi in maniera estremamente elegante.
I design pattern sono ormai considerati una base fondamentale per la progettazione e lo sviluppo di software object-oriented e sono sempre più spesso parte integrante dei migliori framework in circolazione.
La loro utilità non deve giustificarne, però, l'uso smodato, che potrebbe portare ad applicazioni sovradimensionate. È buona norma usare i design pattern solo quando servono ed dopo una corretta analisi, che permetta anche di individuare quello che meglio si addatti al problema da affrontare. L'esperienza ed il buon senso restano strumenti fondamentali.
