[Link]
org/wiki/Design_pattern
Design pattern
Da Wikipedia, l'enciclopedia libera.
Nell'ingegneria del software, un design pattern (schema di progettazione) può essere definito "una soluzione
progettuale generale a un problema ricorrente". Esso non è una libreria o un componente di software
riusabile, quanto piuttosto 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.
I design pattern orientati agli oggetti tipicamente mostrano relazioni ed interazioni tra classi o oggetti, senza
specificare le classi applicative finali coinvolte. Tali pattern risiedono quindi nel dominio dei moduli e delle
interconnessioni. Ad un livello più alto sono invece i Pattern architetturali che hanno un ambito ben più
ampio, descrivendo un pattern complessivo adottato dall'intero sistema.
La differenza tra un algoritmo e un design pattern è che il primo risolve problemi computazionali, mentre il
secondo è legato agli aspetti progettuali del software.
Indice
1 Storia
2 Struttura di un pattern
3 Classificazione dei design pattern
3.1 Pattern creazionali
3.2 Pattern strutturali
3.3 Pattern comportamentali
4 Altri tipi di pattern
4.1 Pattern architetturali
4.2 Pattern di metodologia
4.3 Pattern di concorrenza
5 Bibliografia
6 Voci correlate
7 Altri progetti
8 Collegamenti esterni
StoriaIlin termine fu inizialmente introdotto in architettura in un celebre saggio di Christopher Alexander;
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).
1
[Link]
Struttura di un patternUn 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.
Classificazione dei design patternIcriteri,
design pattern possono essere classificati con diversi
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 (nell'ingegneria del software, ad esempio, si può parlare di 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 creazionaliI 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 (letteralmente, "fabbrica astratta") 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.
Il Builder ("costruttore") 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 ("metodo fabbrica") fornisce un'interfaccia per creare un oggetto, ma lascia che le
sottoclassi decidano quale oggetto istanziare.
La Lazy initialization ("inizializzazione pigra") è la tattica di instanziare un oggetto solo nel momento
in cui deve essere usato per la prima volta. È utilizzato spesso insieme al pattern factory method.
Il Prototype pattern ("prototipo") permette di creare nuovi oggetti clonando un oggetto iniziale, o
prototipo.
Il Singleton ("singoletto") ha lo scopo di assicurare che di una classe possa essere creata una sola
istanza.
Pattern strutturaliI pattern strutturali consentono di riutilizzare degli oggetti esistenti fornendo agli
utilizzatori un'interfaccia più adatta alle loro esigenze.
L'Adapter ("adattatore") converte l'interfaccia di una classe in una interfaccia diversa
Bridge ("ponte") permette di separare l'astrazione di una classe dalla sua implementazione, per
permettere loro di variare indipendentemente.
Il Composite ("composto"), utilizzato per dare la possibilità all'utilizzatore di manipolare gli oggetti in
modo uniforme, organizza gli oggetti in una struttura ad albero.
Il Container ("contenitore") offre una soluzione alla rottura dell'incapsulamento per via dell'uso
dell'ereditarietà.
Il Decorator ("decoratore") consente di aggiungere metodi a classi esistenti durante il run-time (cioè
2
[Link]
durante lo svolgimento del programma), permettendo una maggior flessibilità nell'aggiungere delle
funzionalità agli oggetti.
Extensibility ("estendibilità")
Il Façade ("facciata") permette, attraverso un'interfaccia più semplice, l'accesso a sottosistemi che
espongono interfacce complesse e diverse tra loro.
Flyweight ("peso piuma"), che permette di separare la parte variabile di una classe dalla parte che può
essere riutilizzata.
Proxy fornisce una rappresentazione di un oggetto di accesso difficile o che richiede un tempo
importante per l’accesso o creazione. Il Proxy consente di posticipare l’accesso o creazione al
momento in cui sia davvero richiesto.
Pipes and filters ("condotti e filtri")
Private class data ("dati di classe privati")
Pattern comportamentaliI pattern comportamentali forniscono soluzione alle più comuni tipologie di
interazione tra gli oggetti.
Chain of Responsibility ("catena di responsabilità") diminuisce l'accoppiamento fra l'oggetto che
effettua una richiesta e quello che la soddisfa, dando a più oggetti la possibilità di soddisfarla
Il Command ("comando") permette di isolare la porzione di codice che effettua un'azione dal codice
che ne richiede l'esecuzione.
Event Listener ("ascoltatore di eventi")
Hierarchical Visitor ("visitatore di gerarchia")
Interpreter ("interprete") dato un linguaggio, definisce una rappresentazione della sua grammatica
insieme ad un interprete che utilizza questa rappresentazione per l'interpretazione delle espressioni in
quel determinato linguaggio.
L'Iterator ("iteratore") 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.
Il Mediator ("mediatore") si interpone nelle comunicazioni tra oggetti, allo scopo di aggiornare lo stato
del sistema quando uno qualunque di essi comunica un cambiamento del proprio stato.
Il design pattern Memento ("promemoria") è 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 ("osservatore") 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 ("stato") permette ad un oggetto di cambiare il suo comportamento al cambiare di un suo stato
interno.
Lo Strategy ("strategia") è utile in quelle situazioni dove è necessario modificare dinamicamente gli
algoritmi utilizzati da un'applicazione.
Il Template method ("metodo schema") permette di definire la struttura di un algoritmo lasciando alle
sottoclassi il compito di implementarne alcuni passi come preferiscono.
Il Visitor ("visitatore") 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.
Altri tipi di patternAlcuni pattern definiti nella letteratura non operano a livello di design del
sistema, non possono quindi essere definiti propriamente design pattern.
Alcuni esempi sono:
Pattern architetturaliI pattern architetturali operano ad un livello diverso (e più ampio) rispetto ai
design pattern, ed esprimono schemi di base per impostare l'organizzazione
strutturale di un sistema software. In questi schemi si descrivono sottosistemi predefiniti insieme con i ruoli
che essi assumono e le relazioni reciproche.
3
[Link]
Blackboard, architettura per applicazioni di intelligenza artificiale
Broker
Client-server, rappresenta un tipo di applicazione di rete nel quale un computer client istanzia
l'interfaccia utente di un'applicazione connettendosi ad una server application o ad un sistema di
database.
Layers, archiettura basata su layer
Microkernel
Model-View-Controller (abbreviato spesso in MVC), che consiste nel separare i componenti software
che implementano il modello delle funzionalità di business (model), dai componenti che implementano
la logica di presentazione (view) e da quelli di controllo che tali funzionalità utilizzano (controller).
Naked Objects
Pipes and Filters
Presentation Abstraction Control
Reflection
Repository, pattern architetturale legato ad aspetti di persistenza
Pattern di metodologiaResponsibility, ossia "identificare chiaramente e dividere la responsabilità"
assegnata a ciascun oggetto o componente del sistema, è il pattern metodologico
basilare indicato nel libro Design Patterns.
Make it run, make it right, make it fast, make it small
Pattern di concorrenzaNel caso di processi che eseguono contemporaneamente delle attività su dati
condivisi si parla di concorrenza. Alcuni design pattern sono stati sviluppati per
mantenere sincronizzato lo stato dei dati in tali situazioni:
Active Object
Balking pattern
Double checked locking pattern
Guarded suspension
Leaders/followers pattern
Monitor Object, che consente soltanto un processo attivo al suo interno, al contempo non necessita di
una codifica esplicita della mutua esclusione.
Read-write lock pattern
Scheduler pattern
Thread pool pattern
Thread-Specific Storage
Token passing synchronization
Reactor pattern
BibliografiaGamma, E., Helm, R., Johnson, R. e Vlissides, J., Design Patterns: elementi per il riuso
di software a oggetti, Addison Wesley, 1995, ISBN 88-7192-150-X
Originale: Design Patterns: Elements of Reusable Object-Oriented Software, Addison Wesley,
1995, ISBN 0-201-63361-2
Eckel, B., Thinking in Patterns with Java ([Link] , MindView
(draft)
Voci correlateAnti-pattern
Framework orientato agli oggetti
Altri progetti Wikimedia Commons contiene file multimediali su Design pattern
Collegamenti esterniPortland Pattern Repository ([Link]
Hillside ([Link] Patterns Library
Filosofia dei pattern ([Link]
4
[Link]
/[Link])
Pagina dei pattern di Vince Huston ([Link]
GoF's Design Patterns in Java (in Italiano) ([Link]
Categoria: Teorie della programmazione
Ultima modifica per la pagina: 05:27, 10 mag 2011.
Il testo è disponibile secondo la licenza Creative Commons Attribuzione-Condividi allo stesso modo;
possono applicarsi condizioni ulteriori. Vedi le condizioni d'uso per i dettagli. Wikipedia® è un marchio
registrato della Wikimedia Foundation, Inc.