Design Patterns: i patterns creazionali secondo la Gang Of Four

Design Patterns: Elements of Reusable Object-Oriented Software

Design Patterns – Gang of Four

Design Patterns: Elements of Reusable Object-Oriented Software è stata la prima raccolta comprensiva dei Design pattern per la progettazione di software utilizzando la progettazione ad oggetti all’insegna della massima flessibilità e riusabilità del codice.

I design pattern sono infatti dei pattern, delle soluzioni generiche da applicare in determinati casi, soluzioni eleganti architetturali ottimizzate all’insegna appunto della flessibilità, della riusabilità.

Il libro pubblicato nel 1995, è oggi ancora attuale (tranne forse nel linguaggio utilizzato per gli esempi, lo Smalltalk), ed è tra i più popolari libri sui design pattern (ne esistono molti). In particolare ho deciso di scrivere questa serie di articoli dopo aver letto, su un annuncio di lavoro, che veniva espressamente richiesta la conoscenza dei design pattern definiti dai GoF, ovvero i design pattern definiti in questo libro (il libro è stato scritto da quattro differenti autori, successivamente conosciuti come Gang Of Four, abbreviato in GoF).

Nel libro, i design pattern vengono suddivisi in 3 categorie:

  • Design pattern creazionali
  • Design pattern strutturali
  • Design pattern comportamentali

In questo primo articolo saranno affrontati i design pattern creazionali. Per approfondire la tua conoscenza dell’argomento, puoi acquistare il libro in inglese oppure la sua Versione in italiano.

I design pattern creazionali

I design pattern creazionali sono quei design pattern legati alla creazione (istanziazione) di oggetti, in modo che questi siano riutilizzabili o addirittura intercambiabili.

Factory (o Factory method)

Questo pattern prevede un’oggetto, la Factory che abbia la responsabilità, attraverso vari metodi Factory Methods di instanziare oggetti che appartengono alla stessa famiglia, cioè simili tra loro, che condividono una stessa interfaccia, l’AbstractProduct, che in pratica sono istanze di vari Concrete Products differenti, uno per ogni factory methods.

Questo pattern permette di isolare eventuali client dal tipo di implementazione del Product.

Abstract Factory

E’ un pattern che aggiunge un ulteriore livello di astrazione al pattern Factory method: ora non esiste più una singola Factory, ma un’insieme di ConcreteFactory, tutte le con la stessa interfaccia AbstractFactory e che sono in grado di generare ConcreteProducts differenti ma che implementano la stessa interfaccia.

E’ un pattern un pò complesso da implementare, ma permette una grande flessibilità: posso modificare le classi concrete andando a modificare la ConcreteFactory da invocare, anche a run-time.

Builder

Utilizzo una AbstractFactory (rinominata per l’occasione Builder, per produrre le varie parti di un oggetto complesso, e successivamente utilizzo un oggetto chiamato Constructor per mettere assieme le parti realizzate dal Builder effettuando una composizione dell’oggetto (complesso) desiderato.

Posso passare al Constructor come parametro il Builder e questo si occuperà sia della creazione che della composizione.

E’ un algoritmo utile quando ho oggetti complessi con parti che potrebbero essere interscambiate, oppure voglio mantenere separata la creazione delle singole parti dalla creazione dell’oggetto complesso

Prototype

E’ un design pattern che prevede la creazione di nuove istanze attraverso la clonazione di un oggetto (il prototipo). E’ particolarmente utile quando voglio istanziare in modo veloce una classe molto grande, caricata dinamicamente in precedenza. Il prototipo è una classe stratta o un’interfaccia, in Java dovrà implementare Clonable.

L’inconveniente di questo design pattern è la necessità di implementare l’operazione di clonazione che può essere difficile nel caso di oggetti con riferimenti circolari al loro interno, o con oggetti non copiabili.

Un esempio di applicazione di questo design pattern è per implementare una transazione: faccio una copia, quando la transazione è avvenuta correttamente sostituirò la copia all’originale, non prima.

Esiste una variante di questo pattern che prevede un PrototypeManager che tenga traccia dei differenti tipi di prototipi disponibili (tipi clonabili).

Singleton

E’ un pattern che prevede la dichiarazione del costruttore di una classe come privato, in modo che tale classe sia non istanziabile da client esterni, e allo stesso tempo la definizione di un metodo per creare un’unica istanza della classe, richiamata ogni volta che ce ne sarà bisogno. All’interno di tale metodo, il costruttore privato risulta visibile, quindi la classe è istanziabile: spetta al metodo per richiamare l’istanza della classe assicurarsi che la classe venga istanziata una volta sola, e salvata in un attributo statico (di classe).


Nel prossimo articolo saranno trattati i design pattern strutturali.

Se desideri maggiori informazioni sui design pattern creazionali, ti suggerisco di acquistare il libro della GoF su Amazon (al miglior prezzo).

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *