Design pattern: differenze tra le versioni

Versione delle 11:47, 3 set 2007

Versione attuale delle 19:17, 23 set 2025

(164 versioni intermedie di 99 utenti non mostrate)

Riga 1:

{{nota disambigua|descrizione=il libro|titolo=[[Design Patterns]]}}

{{F|programmazione|aprile 2013}}

Nell'[[ingegneria del software]], un '''''design pattern''''' può({{lett|schema essereprogettuale definitoo schema di progettazione|lingua=it}}) é "una soluzione progettuale di carattere generale a un problema ricorrente". EssoSi non è una libreria o un componentetratta di [[software]] riusabile, quanto una descrizione o un modello logico da applicare per risolverela risoluzione di un problema che può presentarsi in diverse situazioni durante lale fasi di [[Ciclo di vita del software|progettazione e lo sviluppo del software]], ancor prima della definizione dell'[[algoritmo]] risolutivo della parte computazionale. È un approccio spesso efficace nel contenere o ridurre il [[debito tecnico]].

I ''design pattern'' [[programmazione orientata agli oggetti|orientati agli oggetti]] tipicamente mostrano relazioni e interazioni tra [[classe (informatica)|classi]] o [[oggetto (informatica)|oggetti]], senza specificare le classi applicative finali coinvolte, risiedendo quindi nel dominio dei [[modulo (software)|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 cui implementazione logica dà vita a un ''[[framework]]''.

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 [[architettura software|architetture software]], soprattutto [[programmazionequelle orientataorientate agli oggetti|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 [[componente software|sviluppo di software basato su componenti]], ai [[sistema aperto|sistemi aperti]], ai ''[[framework]]'' e così via. La maggior parte dei [[linguaggio di programmazione|linguaggi di programmazione]] moderni, e didelle 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|Design Patterns: Elementi per il riuso di software ad oggetti]]'' di [[Erich Gamma]], [[Richard Helm]], [[Ralph Johnson (informatico)|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 fourFour (scrittori)|Gang of Four]]'' ({{lett|banda dei quattro}}) o ''GofGoF'')..

== 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;

Un ''design pattern'' è costituito da:

* il problema, ovvero la descrizione della situazione alla quale si può applicare il pattern. Può comprendere la descrizione di [[Classe (informatica)|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 [[linguaggio di pattern|linguaggi di pattern]].

* ''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 [[Classe (informatica)|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.

== Classificazione ==

L'uso di [[pattern]] nella descrizione di altri pattern dà origine ai cosiddetti [[linguaggio di pattern|linguaggi di 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]], [[rete informatica|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 suo libro la GoF identificò 23 tipi di design pattern, suddivisi in tre categorie: strutturali, creazionali e comportamentali.

==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 (nell'ingegneria del software, ad esempio, si può parlare di creazione, comportamento, navigazione di oggetti o strutture dati).

=== Pattern creazionali ===

Nel loro [[Design Patterns|libro]] la "[[Gang of four|banda dei quattro]]" identificò 23 tipi di design pattern, suddivisi in 3 categorie: strutturali, creazionali e comportamentali.

I pattern creazionali risolvono problematiche inerenti all'istanziazione degli oggetti

* 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.

===Pattern creazionali===

* 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.

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.

* 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 istanziare 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 (informatica)|singleton]] ("singoletto") ha lo scopo di assicurare che di una classe possa essere creata una sola istanza in sistemi con un unico thread.

* Il [[Interblocco ricontrollato|double-checked locking]] ("Interblocco ricontrollato") ha lo scopo di assicurare che di una classe possa essere creata una sola istanza in sistemi multithread.

=== Pattern strutturali ===

* 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.

I pattern strutturali risolvono problematiche inerenti alla struttura delle classi e degli oggetti.

* [[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. È 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.

* L'[[Adapter pattern|adapter]] ("adattatore") converte l'interfaccia di una classe in una interfaccia diversa.

===Pattern strutturali===

* [[Bridge pattern|Bridge]] ("ponte") permette di separare l'astrazione di una classe dalla sua implementazione, per permettere loro di variare indipendentemente.

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

* 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 pattern|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è durante lo svolgimento del programma), permettendo una maggior flessibilità nell'aggiungere delle funzionalità agli oggetti.

* [[Extensibility pattern|Extensibility]] ("estendibilità")

* Il [[Façade pattern|façade]] ("facciata") permette, attraverso un'interfaccia più semplice, l'accesso a sottosistemi che espongono interfacce complesse e diverse tra loro.

* [[Flyweight pattern|Flyweight]] ("peso piuma"), che permette di separare la parte variabile di una classe dalla parte che può essere riutilizzata.

* [[Proxy pattern|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 pattern|Private class data]] ("dati di classe privati")

=== Pattern comportamentali ===

* L'[[Adapter pattern|Adapter]] converte l'interfaccia di una classe in una interfaccia diversa

* [[Bridge pattern|Bridge]] permette di separare l'astrazione di una classe dalla sua implementazione, per permettere loro di variare indipendentemente.

* 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 pattern|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 pattern|Extensibility]]

* Il [[Façade pattern|Façade]] permette, attraverso un'interfaccia più semplice, l'accesso a sottosistemi che espongono interfaccie complesse e diverse tra loro.

* [[Flyweight pattern|Flyweight]], che permette di separare la parte variabile di una classe dalla parte che può essere riutilizzata.

* [[Proxy pattern|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|Pipes and filters]]

* [[Private class data pattern|Private class data]]

===Pattern comportamentali===

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

* [[Chain of responsibility pattern|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

* [[Chain of responsibility pattern|Chain of Responsibility]]

* Il [[Command pattern|Commandcommand]] ("comando") permette di isolare la porzione di codice che effettua un'azione dal codice che ne richiede l'esecuzione.

* [[Event listener|Event Listener]] ("ascoltatore di eventi")

* [[Hierarchical visitor pattern|Hierarchical Visitorvisitor]] ("visitatore di gerarchia")

* [[Interpreter pattern|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.

* [[Interpreter pattern|Interpreter]]

* L'[[Iterator (design pattern)|Iteratoriterator]] ("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 pattern|Mediatormediator]] ("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 pattern|Mementomemento]] ("promemoria") è l'operazione di estrarre lo stato interno di un oggetto, senza violarne l’incapsulazionel'incapsulazione, e memorizzarlo per poterlo ripristinare in un momento successivo.

* L'[[Observer pattern|Observerobserver]] ("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 pattern|Single-serving Visitorvisitor]]

* [[State pattern|State]] ("stato") permette ad un oggetto di cambiare il suo comportamento al cambiare di un suo stato interno.

* [[State pattern|State]]

* Il design patternLo [[Strategy pattern|Strategystrategy]] ("strategia") è utile in quelle situazioni dove è necessario modificare dinamicamente gli algoritmi utilizzati da un'applicazione.

* Il [[Templatetemplate method]] ("metodo schema") permette di definire la struttura di un algoritmo lasciando alle sottoclassi il compito di implementarne alcuni passi come preferiscono.

* Il [[Visitorvisitor]] ("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.

* [[Null object]] ("oggetto nullo") permette di sostituire un riferimento nullo con un oggetto che non fa nulla.

==Altri tipi di pattern==

== Altri tipi di pattern ==

Alcuni pattern definiti nella letteratura non operano a livello di design del sistema, non possono quindi essere definiti propriamente design pattern. Alcuni esempi sono:

=== Pattern architetturali ===

I 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.

* [[Blackboard pattern|Blackboard]], architettura per applicazioni di intelligenza artificiale

* [[Broker pattern|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.

* [[Model-View-Controller|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'').

* [[Layers pattern|Layers]], architettura basata su layer

* [[Presentation Abstraction Control pattern|Presentation Abstraction Control]]

* [[Microkernel pattern|Microkernel]]

* [[Model-view-controller|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'').

* [[Reflection pattern|Reflection]]

* [[Model-view-viewmodel]] (spesso abbreviato in ''MVVM'')

* [[Layers pattern|Layers]]

* [[Naked objects]]

* [[Pipes and Filters pattern|Pipes and Filters]]

* [[Pipes and filters]]

* [[Blackboard pattern|Blackboard]]

* [[Presentation Abstraction Control pattern|Presentation Abstraction Control]]

* [[Reflection pattern|Reflection]], fornisce un meccanismo per cambiare la struttura e il comportamento di sistemi software in modo dinamico. Supporta la modifica di aspetti fondamentali, quali tipo di strutture e meccanismi di chiamata di funzione.

* [[Repository]], pattern architetturale legato ad aspetti di persistenza

* [[Front controller]], pattern architetturale che prevede l'utilizzo di un singolo file per gestire tutte le richieste

* [[Data Access Object]], per la gestione della [[Persistenza (informatica)|persistenza]]: si tratta fondamentalmente di una [[Classe (informatica)|classe]] con relativi [[Metodo (informatica)|metodi]] che rappresenta un'[[Modello relazionale|entità tabellare]] di un [[RDBMS]].

* [[Data Transfer Object]], per trasferire dati tra sottosistemi di un'applicazione software. I DTO sono spesso usati in congiunzione con gli oggetti di accesso ai dati (DAO) per recuperare i suddetti da una [[base di dati]].

* [[Active record pattern]], tipicamente utilizzato in librerie di persistenza e in [[Object-relational mapping|Object-relational mapper]].

=== Pattern di metodologia ===

* [[Responsibility (design patter)GRASP|Responsibility]], 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 concorrenza ===

Nel caso di processi che eseguono contemporaneamente delle attività su dati condivisi si parla di [[concorrenza (informatica)|concorrenza]]. Alcuni design pattern sono stati sviluppati per mantenere [[sincronizzazione (informatica)dei processi|sincronizzato]] lo stato dei dati in tali situazioni:

* [[Active Object]]

* [[Balking pattern]]

* [[Interblocco ricontrollato|Double checked locking pattern]]

* [[Guarded suspension]]

* [[Leaders followers pattern|Leaders/followers pattern]]

Riga 107 ⟶ 115:

* [[Reactor pattern]]

==Voci correlateBibliografia ==

* [[Erich Gamma|Gamma, E.]], [[Richard Helm|Helm, R.]], [[Ralph Johnson (informatico)|Johnson, R.]] e [[John Vlissides|Vlissides, J.]], '' [[Design Patterns]]: elementi per il riuso di software a oggetti'', Addison Wesley, 1995, ISBN 88-7192-150-X

*[[Anti-pattern]]

** Originale: ''Design Patterns: Elements of Reusable Object-Oriented Software'', Addison Wesley, 1995, ISBN 0-201-63361-2

*[[Framework]] orientato agli oggetti

* [[Bruce Eckel|Eckel, B.]], ''[https://web.archive.org/web/20050408055821/http://www.mindview.net/Books/TIPatterns Thinking in Patterns with Java]'', MindView (draft)

== Voci correlate ==

* [[Anti-pattern]]

* [[Debito tecnico]]

* [[Model-view-controller]]

* [[Observer pattern]]

* [[Pattern]]

== Altri progetti ==

{{interprogetto|preposizione=sul}}

== Collegamenti esterni ==

==Bibliografia==

* {{Collegamenti esterni}}

*[[Erich Gamma|Gamma, E.]], [[Richard Helm|Helm, R.]], [[Ralph Johnson|Johnson, R.]] e [[John Vlissides|Vlissides, J.]], '' [[Design Patterns]]: elementi per il riuso di software a oggetti'', Addison Wesley, [[1995]], ISBN 887192150X

* {{FOLDOC}}

**Originale: ''Design Patterns: Elements of Reusable Object-Oriented Software'', Addison Wesley, [[1995]], ISBN 0201633612

* {{cita web|http://c2.com/cgi/wiki?WelcomeVisitors|Portland Pattern Repository}}

*[[Bruce Eckel|Eckel, B.]], ''[http://www.mindview.net/Books/TIPatterns/ Thinking in Patterns with Java], MindView (draft)

* [http://hillside.net/patterns/ Hillside] Patterns Library

==Collegamenti esterni==

* {{cita web | 1 = http://www.inf.unitn.it/DiplomaUniversitario/JavaCampus/luca_cristoforetti/node16.html | 2 = Filosofia dei pattern | accesso = 7 aprile 2005 | urlarchivio = https://web.archive.org/web/20050316154225/http://www.inf.unitn.it/DiplomaUniversitario/JavaCampus/luca_cristoforetti/node16.html | dataarchivio = 16 marzo 2005 | urlmorto = sì }}

*[http://c2.com/cgi/wiki?WelcomeVisitors Portland Pattern Repository]

* {{cita web|http://www.vincehuston.org/dp/|Pagina dei pattern di Vince Huston}}

*[http://hillside.net/patterns/ Hillside] Patterns Library

* {{cita web | 1 = http://eii.pucv.cl/pers/guidi/designpatterns.htm | 2 = GoF's Design Patterns in Java (in Italiano) | accesso = 6 giugno 2007 | dataarchivio = 27 marzo 2008 | urlarchivio = https://web.archive.org/web/20080327083712/http://eii.pucv.cl/pers/guidi/designpatterns.htm | urlmorto = sì }}

* [http://www.inf.unitn.it/DiplomaUniversitario/JavaCampus/luca_cristoforetti/node16.html Filosofia dei pattern]

*[http://home.earthlink.net/~huston2/dp/patterns.html Pagina dei pattern di Vince Huston ]

*[http://eii.pucv.cl/pers/guidi/designpatterns.htm GoF's Design Patterns in Java (in Italiano)]

{{Design pattern}}

[[Categoria:Teorie della programmazione]]

{{Controllo di autorità}}

{{portale|informatica}}

[[Categoria:Design pattern| ]]

[[ast:Patrón de diseñu]]

[[bs:Računarska dizajn šema]]

[[ca:Patró de disseny (informàtica)]]

[[cs:Návrhový vzor]]

[[da:Design pattern]]

[[de:Entwurfsmuster]]

[[en:Design pattern (computer science)]]

[[es:Patrón de diseño]]

[[fi:Suunnittelumalli]]

[[fr:Motif de conception]]

[[he:תבנית עיצוב]]

[[id:Design pattern]]

[[ja:デザインパターン (ソフトウェア)]]

[[ko:디자인 패턴]]

[[lt:Projektavimo pavyzdys]]

[[nl:Ontwerppatroon]]

[[no:Design pattern]]

[[pl:Wzorzec projektowy (informatyka)]]

[[pt:Padrões de projeto de software]]

[[ru:Шаблоны проектирования]]

[[simple:Design pattern]]

[[sv:Designmönster]]

[[tr:Tasarım kalıpları]]

[[vi:Mẫu thiết kế (khoa học máy tính)]]

[[zh:软件设计模式]]