Design pattern: differenze tra le versioni

Versione delle 18:04, 1 feb 2024

Versione attuale delle 19:17, 23 set 2025

(8 versioni intermedie di 5 utenti non mostrate)

Riga 1:

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

{{F|programmazione|aprile 2013}}

'''Design pattern''' (traducibile in [[lingua italiana]] come "schema progettuale", "schema di progettazione", o "schema architetturale"), in [[informatica]] e specialmente nell'ambito dell'[[ingegneria del software]], è un concetto che può essere definito "una soluzione [[progetto|progettuale]] generale ad un problema ricorrente". Si tratta di una descrizione o modello logico da applicare per la risoluzione di un problema che può presentarsi in diverse situazioni durante le fasi di [[Ciclo di vita del software|progettazione e sviluppo del software]], ancor prima della definizione dell'[[algoritmo]] risolutivo della parte computazionale. È un approccio spesso efficace nel contenere o ridurre il [[debito tecnico]].

Nell'[[ingegneria del software]] un ''Design'''design pattern''''' (traducibile in [[lingua italiana]] come "{{lett|schema progettuale", "o schema di progettazione", o "schema architetturale"|lingua=it}}), in [[informatica]] e specialmente nell'ambito dell'[[ingegneria del software]], è un concetto che può essere definitoé "una soluzione [[progetto|progettuale]] di carattere generale ada un problema ricorrente". Si tratta di una descrizione o modello logico da applicare per la risoluzione di un problema che può presentarsi in diverse situazioni durante le fasi di [[Ciclo di vita del software|progettazione e 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 [[object oriented|orientati agli oggetti]] tipicamente mostrano relazioni ed 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]].

I ''design pattern'' [[objectprogrammazione orientedorientata agli oggetti|orientati agli oggetti]] tipicamente mostrano relazioni ede 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]]''.

== 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|orientato agli oggetti]]. 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 Four (scrittori)|Gang of Four]]'' ({{lett|banda dei quattro}}) o ''GoF'').

== Struttura ==

Riga 20 ⟶ 21:

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

== Classificazione ==

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 lorosuo [[Design Patterns|libro]] la "banda dei quattro"GoF identificò 23 tipi di design pattern, suddivisi in tre categorie: strutturali, creazionali e comportamentali.

=== Pattern creazionali ===

Riga 83 ⟶ 84:

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

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

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

* [[Naked objects]]

Riga 93 ⟶ 94:

* [[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 ===

Riga 99 ⟶ 101:

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

Riga 126 ⟶ 128:

== Altri progetti ==

{{interprogetto|preposizione=suisul}}

== Collegamenti esterni ==

Riga 137 ⟶ 139:

* {{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ì }}

{{Design Patterns patternspattern}}

{{Controllo di autorità}}

{{portale|informatica}}