Modelli di design per principianti

Se hai già scritto programmi per prodotti o applicazioni software, grandi/piccoli, è molto probabile che tu abbia utilizzato molti Design Pattern… anche se è possibile che non siano uno dei più usati/standard design patterns.

Ma sì, c'è un'ovvia differenza tra l'implementazione di un design pattern e "l'utilizzo" di un design pattern... in entrambi i casi, la persona che lavora con i design pattern lo capisce, o lo capirà facilmente.

Il punto è che i modelli di progettazione non sono nuovi per i programmatori.

In questo articolo di seguito, sto cercando di spiegare i modelli di progettazione, nelle sue basi, e studieremo i dettagli di vari modelli, esempi, ecc. in un altro articolo.

Che cos'è un modello di progettazione?

Iniziare…

Penso che il modo migliore per iniziare con la comprensione dei modelli di progettazione sia comprendere i modelli non tecnici che consapevolmente/inconsapevolmente seguiamo nella nostra vita quotidiana.

Ad esempio, prendiamo molti curriculum inviati per un posto vacante. Il curriculum di tutti non sembra uguale... anche se tutti tendono a fare la stessa cosa, cioè dire a un lettore in cosa sono abili o come può essere adatto al lavoro.

La maggior parte di coloro che inviano curriculum ai lavori, sanno che devono presentare un curriculum con un particolare insieme di informazioni in un documento Word formattato.

Questo... è uno schema, per cui tutti inviano un curriculum con un particolare insieme di informazioni espresse in esso.

Se hai voglia... chiamalo Modelli invece di Pattern. Modelli di progettazione.

Ci sono molte cose simili nella vita reale che sono modelli. Ad alcune persone piacciono gli esempi seguenti:

Tutti gli chef di tutto il mondo cucinano la pizza o le patatine fritte allo stesso modo. Anche se possono condire / aromatizzarlo in modo diverso. Questo è uno schema.

Il design di ogni auto segue uno schema di progettazione di base, quattro ruote, volante, il sistema di trasmissione principale come acceleratore-freno-frizione, ecc.

Tutte le cose ripetutamente costruite / prodotte, seguiranno inevitabilmente uno schema nel suo design... che si tratti di automobili, pizza, bancomat, qualunque cosa... persino spazzolino da denti.

Progetti che sono diventati quasi un modo standard per codificare una certa logica/meccanismo/tecnica nel software, quindi sono diventati noti come - e quindi - studiati come Software Design Patterns.

Perché è importante un modello di progettazione?

Fondamentalmente per due motivi:

1. Per attenersi a uno standard
2. Per accelerare lo sviluppo

Spiegherò in dettaglio.

In primo luogo, vediamo perché è interessante attenersi a uno schema standard.

Prendiamo l'elenco degli esempi di curriculum di cui abbiamo discusso prima.

Potrebbero esserci uno o due candidati che inviano le loro domande di lavoro tramite testo e-mail senza una formattazione adeguata, senza allegati alla loro e-mail, ecc., .. questi uno o due candidati non stanno seguendo lo schema.. e NON è probabile che finiscano con il lavoro…. perché? Perché si discostano da uno schema ben consolidato, che potrebbe non piacere alle persone che selezionano i curriculum per il lavoro.

Non c'è nessuno che devia dal modello e diventa "cool"? Non è innovazione?

Sì, ci sono volte in cui un curriculum presentato in modo molto diverso ottiene il lavoro per essere diverso dagli altri. Di solito ho sentito parlare di web designer che hanno ottenuto lavori di prim'ordine perché hanno compilato e presentato un film in CD del loro lavoro, o hanno creato un personaggio di animazione che spiega il loro lavoro, l'hanno pubblicato sul loro blog e cose del genere.

Ma.. questa è sperimentazione (l' innovazione nasce da esperimenti riusciti ).

Molto spesso nello sviluppo di software, non puoi permetterti di sperimentare, a causa della pressione della sequenza temporale, delle aspettative, ecc., ma sì, a volte, alcuni progetti interessanti consentono qualche sperimentazione.

Nel software, non possiamo fare cose di base come un deposito bancario... in 101 modi... ci saranno solo alcuni modi per elaborare un deposito bancario... quindi ha senso seguire uno schema consolidato e testato.

Inoltre, la maggior parte dei modelli di progettazione ha variazioni... alcune delle variazioni sono così popolari che le variazioni saranno anche un nuovo tipo standard di modello.

I progetti software in questi giorni dovrebbero (almeno implicitamente) seguire un design già stabilito di un prodotto/software simile sul mercato.

È qui che attenersi a uno stile standard di codifica o modello di progettazione aiuta lo sviluppo del software... velocizzando lo sviluppo, eliminando il sovraccarico di preoccuparsi di una nuova implementazione non testata, ecc.

Tempo di sviluppo del fissaggio

Seguire un modello di progettazione standard ha anche il vantaggio di comunicare facilmente attraverso l'albero/gerarchia di architetti del software, lead del modulo, lead del team, sviluppatori ecc., su "Come" qualcosa deve essere sviluppato e non solo "Cosa" deve essere sviluppato.

A volte aiuta anche i team di test, perché i tester saprebbero per esperienza che il codice che segue un particolare modello di progettazione probabilmente potrebbe essere testato in un modo specifico con una serie di strumenti di test in un certo periodo di tempo e tali progetti noti potrebbero non presentare alcuni difetti o avere alcuni difetti "noti".

L'uso di Design Patterns non toglie un tocco personale?

No. In primo luogo perché non stiamo dicendo che segui un modello di progettazione e non succede nient'altro. La maggior parte delle implementazioni di progetti condivide solo i requisiti di base con altri progetti e molto probabilmente presenterà deviazioni. La costruzione di queste deviazioni richiederà la flessione e l'allungamento dei modelli standard utilizzati in un'implementazione.

È come fare la pizza nel modo standard, poi condirla / presentarla a diverse esigenze, come una pizza intera, o una torta tagliata, o altro.

Per comprendere l'importanza dei modelli di progettazione, una cosa è molto **importante :

I Design Pattern non sono tecnologie o framework che una particolare azienda o un linguaggio di programmazione ci impone. Ciò significa che è come un concetto aperto... sei libero di prenderlo, usarlo, modificarlo in base alle tue esigenze e, soprattutto... sentirlo come tuo.

Tutti i modelli di design standard o popolari, in realtà, sono estensibili abbastanza pesantemente.. sono diventati popolari, in primo luogo, solo perché molte persone lo usano.. e molte persone lo usano solo perché sono flessibili alle loro esigenze.

O come pensi che un modello di design standard si adatterebbe a un progetto nel New Jersey per un'azienda e anche a Bangalore per un'altra azienda e un diverso tipo di progetto.

Questo ci porta a " La maggior parte dei modelli di progettazione sono generici "... il che significa che non vengono sempre utilizzati per creare lo stesso tipo di software. Potresti non sentire cose come "Modello di progettazione del software bancario" o "Modello di progettazione del software di social networking" usato nelle discussioni comuni... ma solo "Modelli di progettazione".

Chi dovrebbe preoccuparsi dei modelli di progettazione?

1. Proprio come un buon architetto edile accresce le sue capacità di progettazione di edifici, studiando l'architettura e il design di numerosi edifici e forme nel corso della sua vita, un architetto software dovrebbe studiare e visualizzare come vengono progettati o progettati diversi sistemi software/tecnologici in tutto il mondo architettato.
2. E proprio come i lavoratori edili di un edificio dovrebbero essere consapevoli dei diversi modi di implementare un progetto di edificio, sia per esperienza personale che per comprensione dell'architetto dell'edificio.

Gli sviluppatori/programmatori di software dovrebbero comprendere i modelli di progettazione del software di base e il loro codice di implementazione... da soli o dal Software Architect che istruisce il team a svilupparlo seguendo un modello particolare.

Modelli di codice di base

Nelle righe di apertura di questo articolo, ho detto che qualsiasi programmatore avrebbe utilizzato modelli di progettazione. Di seguito sono riportati alcuni esempi molto semplici di codice che seguono uno schema.

1. Di seguito è riportato un modello di progettazione di base del filtro di intercettazione .
2. Nascondi copia codice
3. [codice]
   interruttore (condizione){
   caso Valore1:
   caso Valore2:
   predefinito:
   }
   [/codice]
4. I trigger di eventi, i gestori di eventi... rientrano nel modello di progettazione Soggetto-Osservatore di base. Discuteremo gli standard di ogni modello, le variazioni popolari, con esempi... presto.
5. Se hai utilizzato una sorta di raccolte, come Arraylist in C#, e hai eseguito un'iterazione nell'array, hai utilizzato un modello di progettazione Iterator di base.
6. Il codice seguente è un esempio di un modello base di gestione delle eccezioni/ catena di responsabilità .
7. Nascondi copia codice
8. [codice]
   Tentativo{
   }cattura (eccezione ex){
   }
   finalmente{
   }
   [/codice]

Diverse aree di modelli di progettazione

Ci sono diverse terminologie nel software diverse dai Design Patterns... alcune spesso si riferiscono a Design patterns di cui abbiamo discusso finora... e altre del tutto non correlate.

Ciò di cui abbiamo discusso finora sopra è talvolta chiamato " Modelli di progettazione dell'implementazione ".

Ce ne sono altri, come Architecture Patterns, Framework Patterns, Language Patterns (per lo più chiamati Language Constructs).

Sono modelli posti a livelli diversi... come i modelli di linguaggio sono modelli implementati come parte di linguaggi di programmazione come C# / Java, come le caratteristiche/costrutti del linguaggio... alcuni di loro li abbiamo già visti.

Tutti gli esempi di cui sopra di soggetto-osservatore, filtro di intercettazione, ecc., sono assorbiti come costrutti linguistici in tutti i popolari linguaggi di programmazione di alto livello che sono venuti dopo C.

I modelli di architettura sono quei modelli standard di architettura del software, comunemente riferiti a diversi metodi di posizionamento o collegamento di moduli o livelli o livelli, che costituiscono l'applicazione completa.

Questo è del tutto estraneo ai modelli di progettazione nel senso di codifica/programmazione che... ma condividono le stesse risposte a Perché/Cosa è discusso in questo articolo.

Anche i modelli di struttura non sono correlati alla nostra discussione sui modelli di progettazione. Quando framework come .NET implementano mezzi speciali per la registrazione degli errori o il tracciamento delle route di esecuzione del codice facilmente attraverso i metodi o gli oggetti integrati nel framework, tali meccanismi sono indicati come modelli di Framework.

Alcuni esempi in .NET Framework includono la funzionalità stackTrace, la funzionalità dell'attributo di classe con [] parentesi quadre sopra le definizioni di classe/metodo e così via. Quando si utilizzano tali funzionalità, si codifica con i modelli integrati del Framework.

Spero che questo articolo aiuti a fornire una panoramica dei modelli di progettazione e delle relative terminologie.

Finora, abbiamo discusso solo di quali sono gli standard e di quanto siano importanti... ma non abbiamo discusso di quali siano i modelli standard stessi.

Licenza

Questo articolo, insieme a qualsiasi codice sorgente e file associati, è concesso in licenza in base a The Code Project Open License (CPOL).