Design pattern: differenze tra le versioni

Versione delle 14:02, 16 set 2022

Versione attuale delle 17:03, 6 nov 2024

(10 versioni intermedie di 7 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]].

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

== 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 [[programmazione orientata agli oggetti|object-orientedorientato 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 [[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 di tecnologie correlate, sono stati progettati (o modificati) tenendo conto anche dell'obiettivo di essere coerenti con questo approccio emergente allo sviluppo del software.

Riga 13:

== Struttura ==

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;

* ''il nome'', costituito da una o due parole che siano il più possibile rappresentative del pattern stesso;

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

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

Line 31 ⟶ 30:

I pattern creazionali risolvono problematiche inerenti all'istanziazione degli oggetti

* L'[[Abstractabstract 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 [[Builderbuilder]] ("costruttore") separa la costruzione di un oggetto complesso dalla sua rappresentazione, in modo che il processo di costruzione stesso possa creare diverse rappresentazioni.

* Il [[Factoryfactory method]] ("metodo fabbrica") fornisce un'interfaccia per creare un oggetto, ma lascia che le sottoclassi decidano quale oggetto istanziare.

* La [[Lazylazy 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 [[Prototypeprototype pattern]] ("prototipo") permette di creare nuovi oggetti clonando un oggetto iniziale, o prototipo.

* Il [[Singleton (informatica)|Singletonsingleton]] ("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|Doubledouble-checked locking]] ("Interblocco ricontrollato") ha lo scopo di assicurare che di una classe possa essere creata una sola istanza in sistemi multithread.

=== Pattern strutturali ===

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

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

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

* Il [[Compositecomposite]] ("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|Containercontainer]] ("contenitore") offre una soluzione alla rottura dell'incapsulamento per via dell'uso dell'ereditarietà.

* Il [[Decoratordecorator]] ("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çadefaç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.

Line 57 ⟶ 56:

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

* [[Chain of responsibility pattern|Chain of Responsibilityresponsibility]] ("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 pattern|Commandcommand]] ("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 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.

* L'[[Iterator 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 [[Memento pattern|Mementomemento]] ("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 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.

* Lo [[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 pattern|Null object]] ("oggetto nullo") permette di sostituire un riferimento nullo con un oggetto che non fa nulla.

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

Line 85 ⟶ 83:

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

* [[Microkernel pattern|Microkernel]]

* [[Model-Viewview-Controllercontroller|Model-Viewview-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|Model-Viewview-ViewModelviewmodel]] (spesso abbreviato in ''MVVM'')

* [[Naked objects]]

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

* [[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|Front Controllercontroller]], 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 ===

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

Line 123 ⟶ 122:

* [[Anti-pattern]]

* [[Debito tecnico]]

* [[Model-Viewview-Controllercontroller]]

* [[Observer pattern]]

* [[Pattern]]

== Altri progetti ==

{{interprogetto|preposizione=sul}}

== Collegamenti esterni ==

* {{Collegamenti esterni}}

* {{FOLDOC}}

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

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

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

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

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