Un modello di progettazione è la forma riutilizzabile di una soluzione a un problema di progettazione. L’idea è stata introdotta dall’architetto Christopher Alexander ed è stata adattata per varie altre discipline, in particolare l’informatica.

Modelli di progettazione del software
I modelli di progettazione del software sono proposte di soluzioni generali che sono state sviluppate per risolvere problemi simili riscontrati frequentemente durante la progettazione del software. Sebbene i modelli di progettazione del software siano generalmente definiti indipendentemente dai linguaggi di programmazione, sono più comunemente noti modelli di progettazione software adatti ai linguaggi di programmazione orientati agli oggetti. Questi modelli mostrano le relazioni e le interazioni tra oggetti e classi. Il programmatore può personalizzare un modello di progettazione osservando il problema nella sua mano.

Dettagli
Una raccolta organizzata di modelli di progettazione che si riferiscono a un particolare campo è chiamata linguaggio del modello. Questo linguaggio fornisce una terminologia comune per discutere le situazioni con cui i progettisti devono confrontarsi.

Gli elementi di questo linguaggio sono entità chiamate modelli. Ogni schema descrive un problema che si verifica più e più volte nel nostro ambiente e quindi descrive il nucleo della soluzione a tale problema, in modo tale che è possibile utilizzare questa soluzione un milione di volte, senza mai farlo nello stesso modo due volte . – Christopher Alexander

La documentazione di un modello richiede di spiegare perché una particolare situazione causa problemi e come i componenti del modello si correlano tra loro per fornire la soluzione. Christopher Alexander descrive problemi di progettazione comuni come derivanti da “forze in conflitto” – come il conflitto tra il desiderio di una stanza di essere soleggiato e il suo desiderio di non surriscaldarsi nei pomeriggi estivi. Un modello non direbbe al progettista quante finestre inserire nella stanza; invece, proporrà un insieme di valori per guidare il progettista verso una decisione che è la migliore per la loro particolare applicazione. Alexander, ad esempio, suggerisce di includere abbastanza finestre per dirigere la luce tutt’attorno alla stanza. Considera questa una buona soluzione perché crede che aumenti il ​​godimento della stanza da parte dei suoi occupanti. Altri autori potrebbero giungere a conclusioni diverse, se attribuiscono un valore maggiore ai costi di riscaldamento o ai costi dei materiali. Questi valori, usati dall’autore del modello per determinare quale soluzione è “migliore”, devono essere documentati all’interno del modello.

La documentazione del modello dovrebbe anche spiegare quando è applicabile. Poiché due case possono essere molto diverse l’una dall’altra, un modello di progettazione per le case deve essere sufficientemente ampio da applicarsi a entrambe, ma non così vago da non aiutare il progettista a prendere decisioni. L’intervallo di situazioni in cui un modello può essere utilizzato è chiamato il suo contesto. Alcuni esempi potrebbero essere “tutte le case”, “tutte le case a due piani” o “tutti i luoghi in cui le persone trascorrono del tempo”.

Ad esempio, nel lavoro di Christopher Alexander, le fermate degli autobus e le sale d’attesa in un centro di chirurgia sono entrambe nel contesto del modello “A PLACE TO WAIT”.

Classi di modelli di progettazione
Il libro dei modelli di quadrupla banda (ISBN 0-201-63361-2) distingue tre modelli di schemi di progettazione, ma non esiste un criterio preciso che li separi gli uni dagli altri.

Modelli di creazione
I pattern di creazione forniscono suggerimenti su come creare oggetti software (o in altre parole, istanze di classe). L’idea è che un buon software deve essere progettato indipendentemente da come vengono creati gli oggetti in esso contenuti. In altre parole, dove e come vengono creati gli oggetti non influisce sul funzionamento del software a cui appartengono; le nuove funzionalità non dovrebbero essere aggiunte e problemi con le modifiche.

Man mano che i sistemi software evolvono, la composizione degli oggetti acquisisce maggiore importanza rispetto all’ereditarietà delle classi. La ragione di ciò è che i progetti basati sulla definizione di semplici modelli di comportamento di base per i sistemi software sono più flessibili dei progetti basati su un comportamento fisso. In altre parole, l’aggiunta di comportamenti agli oggetti come combinazione consente di modificare il comportamento successivo in base allo sviluppo del software. In questo caso, un progetto basato sui requisiti comportamentali di base per il software sviluppato consente di utilizzare comportamenti diversi o più complessi senza modificare le interfacce dell’oggetto.

Tuttavia, è più difficile campionare oggetti che forniscono un comportamento di base tramite combinazioni oggettive o creare oggetti da classi derivate ereditando o alterando il comportamento. I modelli di creazione includono schemi software che possono essere utilizzati per superare queste difficoltà.

I modelli di creazione memorizzano nel sistema software quali classi concrete sono utilizzate nell’istanza dell’oggetto e come queste istanze vengono create e assemblate.

Metodo di fabbrica
Assorbendo il modo in cui l’oggetto lo crea sotto la singola interfaccia utilizzata per la creazione dell’oggetto, lascia le funzioni di creazione dell’oggetto nell’interfaccia lasciandola alle sottoclassi.

Esempio (modello prototipo)
Quando creano oggetti da classi complesse e / o costose, consentono di creare nuovi oggetti campionando da quelli esistenti invece di essere creati dall’inizio. In questo modo, i nuovi oggetti sono facilmente creati e le risorse non sono occupate inutilmente.

Modello di fabbrica astratta
Una singola interfaccia consente di creare una famiglia di oggetti su piattaforme diverse. Questa applicazione software numerata può essere spostata su platfroms diversi senza modifiche comportamentali. Il pattern factory astratto mantiene le classi concrete utilizzate in una singola interfaccia.

Modello di generatore
Permette di creare un gruppo complesso di oggetti in pezzi secondo necessità attraverso una singola interfaccia. Quando l’utente utilizza il gruppo di oggetti, il gruppo di oggetti è strutturato nella direzione richiesta. Le parti non utilizzate vengono create inutilmente e non consumano risorse.

Il modello singleton
In una classe, viene creato un solo oggetto da creare. È possibile accedere a questo oggetto da qualsiasi punto dell’applicazione. L’oggetto non può essere creato fino a quando non viene utilizzato per la prima volta.

Schemi strutturali
Fornisce suggerimenti che consentono di costruire strutture software più ampie combinando classi e oggetti strutturali del modello. I modelli di struttura di classe e i modelli di struttura dell’oggetto sono divisi in due.

I modelli di struttura delle classi estendono i costrutti utilizzando l’ereditarietà delle classi o le applicazioni di composizione. I modelli di struttura degli oggetti mostrano come combinare gli oggetti per ottenere nuove funzioni.

Modello composito
Consente agli oggetti di essere combinati insieme in una relazione intera pezzo con una struttura ad albero, e questo composto può essere raggiunto da una singola interfaccia. La struttura composta può espandersi e contrarsi nel tempo aggiungendo e rimuovendo nuovi oggetti.

Facciata (modello di facciata)
Permette di utilizzare una struttura complessa insieme in un’unica interfaccia.

Motivo decorativo
Consente a un oggetto di aggiungere nuove responsabilità senza modificare l’oggetto. Rende possibile migliorare la funzionalità degli oggetti senza sottoclassificazione.

Modello di ponte
Permette di separare l’interfaccia e l’implementazione concreta l’una dall’altra. La modifica dell’interfaccia non influisce sull’interfaccia. Entrambi possono essere sviluppati indipendentemente.

Modello di peso leggero
Invece di creare un numero elevato di oggetti simili, consente la creazione di una struttura di oggetti affollata creando oggetti visivi da un oggetto di esempio. Le variabili di stato degli oggetti visuali sono memorizzate dall’utente, non dall’oggetto stesso.

Modello adattatore
È usato per adattare le interfacce di oggetti o classi da diverse fonti.

Modello Proxy
È possibile imitare l’interfaccia per utilizzare oggetti complicati, costosi e difficili da costruire. Permette di nascondere l’orientamento dell’oggetto fisico dell’oggetto da nascondere all’utente.

Modelli di comportamento
I modelli comportamentali forniscono suggerimenti su come le responsabilità funzionali possono essere assegnate tra gli oggetti e su come i metodi di soluzione richiesti dal software possono essere utilizzati obiettivamente. Gli schemi comportamentali forniscono anche oggetti e modelli di classe, nonché modelli correlati alla comunicazione tra oggetti. I modelli comportamentali consentono al progettista di concentrarsi sui metodi di comunicazione e comunicazione tra gli oggetti.

Anche gli schemi comportamentali sono divisi in due, così come sono nei modelli strutturali: modelli di comportamento di classe e modelli di comportamento degli oggetti.

I modelli di comportamento di classe consentono di distribuire il comportamento tra classi utilizzando l’ereditarietà. I modelli di comportamento degli oggetti consentono di ottenere un comportamento attraverso un gruppo di oggetti che non può essere facilmente raggiunto da un singolo oggetto attraverso la composizione di un oggetto.

Modello di mediatore
Gli oggetti collegati tra loro possono essere guidati da un singolo punto (cioè dal cercatore) sotto lo stesso tetto. Gli oggetti collegati al search finder comunicano le modifiche di stato al search finder. Il finder trova richieste da oggetti relativi all’editing e all’ordinazione richiesti dall’applicazione. Gli oggetti utente di livello superiore si connettono solo al finder.

Modello di stato
Permette ad un oggetto di cambiare il suo comportamento in base alla sua situazione. Dal punto di vista dell’utente, dà l’impressione che stai modificando la classe dell’oggetto. Permette di aggiungere e rimuovere nuovi comportamenti nella direzione richiesta dall’applicazione. Gli oggetti utente non sono interessati da tali modifiche.

Modello di osservatore
Consente a un gruppo di oggetti, osservatori, di essere automaticamente informati delle modifiche in un oggetto osservato. L’oggetto in osservazione continua a funzionare indipendentemente da chi viene monitorato. È possibile che nuovi osservatori partecipino o se ne vadano in tempo. In questo modo l’applicazione può modificare il comportamento nel tempo.

Modello metodo di modello
Permette di usare una procedura come modello di soluzione. Rende possibile che alcune fasi di elaborazione sullo stampo vengano elaborate da sottoclassi. Pertanto, alcuni passaggi intermedi possono essere modificati senza modificare il modello principale. Gli utenti non sono a conoscenza di questi cambiamenti.

Modello di comando
Rende possibile che le richieste dell’utente (obiettivo) vengano trasformate in oggetti ed elaborate. In questo modo, i desideri dei diversi utenti possono essere convertiti in record oggettivi e conservati in code o record. È anche possibile invertire le transazioni effettuate su questo deposito.

Catena di responsabilità (modello di catena di responsabilità)
Un utente (obiettivo) consente di valutare la richiesta da più oggetti da soddisfare. l’utente trasmette la richiesta attraverso una singola interfaccia. Le richieste vengono affrontate a turno dagli oggetti connessi alla richiesta. La richiesta viene trasferita da un oggetto a un altro sulla catena finché non viene accolta. È possibile aggiungere o rimuovere nuovi oggetti nella catena nel tempo. L’utente non è influenzato dall’interfaccia da tali modifiche.

Modello interprete
Lo pseudo-linguaggio definito per soddisfare i requisiti di applicazioni complesse è un modello di interprete. La pseudo-lingua consente alle regole grammaticali di essere facilmente applicate definendole come classi. Poiché le regole grammaticali sono definite come classi, possono essere facilmente modificate e migliorate.

Yadigâr (modello di memento)
Yadigâr viene utilizzato per nascondere gli stati degli oggetti che svolgono ruoli importanti nel software applicativo e per ricordare o ricordare quando necessario.

Pattern Iterator
Garantisce che gli oggetti posizionati sotto un oggetto di massa (Aggragate Object) possano essere raggiunti in sequenza, indipendentemente da come gli oggetti sono rappresentati o realizzati. Gli oggetti rappresentati in questo modo sono accessibili tramite un’unica interfaccia.

Strategia (plagio strategico)
Sotto la stessa interfaccia, molti metodi di soluzione che possono risolvere lo stesso problema nascondono la classe, rendendo possibile soddisfare richieste di oggetti utente senza essere consapevoli del metodo utilizzato. L’utente si trova di fronte a diverse forme di comportamento quando afferma di lavorare con lo stesso tipo di oggetto.

Modello visitatore
Permette di aggiungere nuove operazioni su una struttura composta. Il visitatore visita i singoli oggetti all’interno della struttura composta, raccoglie le informazioni necessarie, le elabora e le presenta all’utente.