Design pattern: programmare in modo più rapido e sicuro
Ogni design ha un suo pattern, tutti hanno però un modello: che sia una tazza, un appartamento o un abito. A nessuno verrebbe mai in mente l’idea di applicare il manico dentro una tazza, eccetto forse ai produttori di articoli a scopo di divertimento. Se seguite un corso di ceramica e volete realizzare un vaso con il manico, la forma vi è conosciuta in linea di massima, e quindi potremmo dire che questa forma è già presente nella vostra testa come uno schema progettuale.
Con i programmi informatici si verifica qualcosa di simile: determinati processi tendono sempre a ripetersi, per questo è nata l’idea di creare dei modelli. Nella nostra guida scoprirete come questi schemi progettuali (chiamati design pattern) possono semplificare il lavoro di programmazione.
Cosa sono i design pattern?
Il termine “design pattern” è da attribuirsi all’architetto statunitense Christopher Alexander, che mise insieme in una raccolta tutti i modelli riutilizzabili. Il suo obiettivo era coinvolgere gli utenti futuri di edifici nella fase di progettazione. Quest’idea è stata poi ripresa da diversi informatici. La cosiddetta Gang of Four (GoF), composta da Erich Gamma, Richard Helm, Ralph Johnson e John Vlissides ha rappresentato un punto di svolta nei software design pattern con il libro “Design Patterns – Elements of Reusable Object-Oriented Software” (it. “Design Patterns: Elementi per il riuso di software ad oggetti) pubblicato nel 1994.
Di cosa si tratta allora? Per riprendere il nostro esempio di prima, per ogni tazza sono necessari sempre gli stessi elementi di base: un fondo, un corpo centrale e un manico, non importa se diventerà una tazza per caffè americano, espresso o tè. Qualcosa di simile si verifica durante la programmazione: i cicli do-while sono sempre inseriti all’inizio e alla fine; una condizione richiede sempre una decisione su cosa accade in caso di concordanza e in caso di non concordanza; un calcolo riporta il risultato della combinazione di variabili e, tra le varie cose, da tanti piccoli passaggi di programmazione nasce l’esecuzione del programma che ha sempre le stesse caratteristiche per compiti precisi. Gli schemi progettuali descrivono come risolvere un problema.
Qui di seguito vi presentiamo un esempio molto semplice di software design pattern, in questo caso di factory method:
class tazze
{
private $tazzaMake;
private $tazzaModel;
public function __construct($make, $model)
{
$this->tazzaMake = $make;
$this->tazzaModel = $model;
}
public function getMakeAndModel()
{
return $this->tazzaMake .'' .$this->tazzaModel;
}
}
class TazzeMateriale
{
public static function create($make, $model)
{
return new Tazza($make, $model);
}
}
$espresso = TazzeMateriale::create('Tazza', 'Espresso'); // Oggetto creato
print_r($espresso->getMakeAndModel()); // Risultato "Tazza Espresso"Lo stesso vale per i legami e i processi applicati in modo ciclico per risolvere compiti precisi nell’esecuzione dei programmi. L’esempio di codice si può ampliare a piacimento, anche in altri settori, per prodotti del tutto diversi o altri processi. Ed è naturalmente solo un elemento di un software molto più ampio. Quindi gli schemi progettuali devono essere considerati come modelli che si sono affermati nella pratica.
Che tipo di design pattern esistono?
I tipi di schemi progettuali rappresentano i principali campi di applicazione dei software design pattern in essi assemblati.
Modelli strutturali
I cosiddetti structural patterns sono degli schemi preimpostati per i legami tra le classi. Con essi si mira a un’astrazione che possa comunicare anche con altre soluzioni; la parola chiave è programmazione di interfacce.
Modelli comportamentali
Con i behavioral pattern si modella il comportamento del software. Questi pattern semplificano processi complessi di comando e controllo. Si può scegliere tra algoritmi e responsabilità di oggetti.
Modelli creazionali
I creational patterns permettono di creare oggetti che rappresentano in modo semplificato istanze precise, indipendentemente dal modo in cui i singoli oggetti sono creati e rappresentati in un software.
Nel corso degli anni si sono aggiunti altri tipi di schemi progettuali, che non rientrano in nessuna delle tre categorie citate. Di questi fanno parte i modelli di mappatura relazionali a oggetti, per memorizzare oggetti e relativi legami in una banca dati relazionale.
Pro e contro relativi all’utilizzo dei design pattern
Vantaggi
La possibilità di attingere a soluzioni valide va di pari passo con un risparmio di tempo e costi. I team di sviluppatori non devono costantemente ripartire da zero per trovare una soluzione per un nuovo programma in caso di problemi già parzialmente risolti. Di solito, i singoli schemi vengono denominati in base a un vocabolario comune di termini tecnici, semplificando in questo modo sia la discussione tra sviluppatori, sia la comunicazione con l’utente destinatario della soluzione finale. Si semplifica anche la documentazione di un software, considerato che possono essere utilizzate componenti già documentate in precedenza. Tutti questi vantaggi aiutano nella fase di manutenzione e ulteriore sviluppo di un programma.
Svantaggi
L’utilizzo degli schemi progettuali richiede un ampio bagaglio di conoscenze pregresse. Inoltre, la disponibilità di design pattern può anche far credere che gli schemi progettuali presenti possano risolvere quasi tutti i problemi. Detto in parole povere: questo può limitare la creatività e la curiosità di trovare soluzioni nuove (e migliori).
Quali sono i design pattern più noti?
Esistono più di settanta schemi progettuali, ordinati in diverse categorie. Alcuni software design pattern importanti sono ad esempio (in grassetto nella spiegazione viene riportata per alcuni anche la denominazione in italiano):
Modelli creazionali
- Builder Pattern: il costruttore nella categoria dei pattern creazionali separa lo sviluppo di oggetti (complessi) dalle loro rappresentazioni.
- Factory Pattern: come pattern, il factory method crea un oggetto attraverso il richiamo ad un metodo invece che a un costruttore.
- Singleton Pattern: come pattern, il singleton fa in modo che per ogni classe esista solo un’unica istanza. Per di più un singleton è disponibile a livello globale.
Modelli strutturali
- Composite Pattern: un pattern strutturale composto, chiamato in inglese composite, rivolto principalmente alle strutture dinamiche, per es. per l’organizzazione o la compressione di dati.
- Decorator Pattern: il cosiddetto decorator integra le classi esistenti di ulteriori funzionalità o responsabilità.
- Facade Pattern: il modello facciata rappresenta un’interfaccia verso altri sistemi, sottosistemi o subsistemi.
Modelli comportamentali
- Observer Pattern: l’osservatore trasmette alle strutture le modifiche apportate a un oggetto, che dipendono dall’oggetto iniziale.
- Strategy Pattern: la strategia definisce una famiglia di algoritmi intercambiabili.
- Visitor Pattern: il visitatore permette di isolare le operazioni eseguibili, in modo da compiere nuove operazioni senza modificare le classi interessate.
I design pattern mettono a disposizione modelli preimpostati con i quali risolvere un problema esplicito, attingendo da un progetto affidabile. Il modello si costruisce su un software design già esistente e coinvolge l’utente nella soluzione futura del processo di progettazione. Inoltre, gli schemi progettuali non sono legati a un linguaggio di programmazione e sono quindi applicabili a livello universale.