Modelli di progettazione

1.1 Introduzione ai modelli

Come accennato in precedenza, un programmatore inizia a lavorare su un programma progettandone il modello: compilando un elenco di entità su cui opererà il programma. E più entità sono nel programma, più complesso è il programma.

Pertanto, al fine di ridurre la complessità del programma, cercano di standardizzare le interazioni degli oggetti. Ed è qui che i modelli di progettazione oi modelli di progettazione aiutano molto il programmatore . Dal modello di design inglese .

Importante! In russo, la parola design di solito significa design grafico, in inglese non è così. La parola inglese design ha un significato più vicino alla parola “design” e/o “device”. Ad esempio, il design di un motore non è il suo aspetto, ma la sua struttura interna.

Pertanto, un design pattern è esattamente un design pattern/pattern. Ti consiglio di smettere del tutto di usare la parola design nel senso di "apparenza". Tu sei il futuro Software Engineer, e per te il design è esattamente design.

Allora, qual è questo modello di progettazione? Prima di tutto, un modello di progettazione è una soluzione standard a un problema standard . Una buona soluzione, efficace e collaudata nel tempo.

Diciamo che ti è stato chiesto di progettare una bicicletta, puoi realizzarla a due ruote, tre o anche cinque. Quindi, tra l'altro, agli albori del design lo era. Ma l'approccio collaudato è su due ruote. Ma l'attuale approccio ovvio ha attraversato dolori ed errori:

In genere, un modello non è una soluzione completa che può essere convertita direttamente in codice, è solo un esempio di una buona soluzione a un problema che può essere utilizzato in varie situazioni.

I modelli orientati agli oggetti mostrano le relazioni e le interazioni tra classi o oggetti , senza specificare quali classi finali o oggetti dell'applicazione verranno utilizzati.

1.2 Storia dei design pattern

Negli anni '70, i programmatori si trovavano di fronte alla necessità di sviluppare programmi di grandi dimensioni su cui dovevano lavorare interi team di sviluppo. Sono stati provati vari metodi di organizzazione del lavoro, ma l'industria delle costruzioni ha influenzato maggiormente lo sviluppo.

Per organizzare il lavoro di un grande gruppo di persone, sono state utilizzate le pratiche e gli approcci del settore edile. A proposito, è stato da lì che termini come assembly (build), Software Developer (builder) e il concetto di architettura sono entrati nella programmazione.

E come puoi immaginare, anche l'idea del modello di progettazione è stata presa dal settore delle costruzioni. Il concetto di pattern è stato descritto per la prima volta da Christopher Alexander in The Pattern Language. Città. Edificio. Costruzione". In questo libro, un linguaggio speciale, i modelli, è stato utilizzato per descrivere i processi di progettazione della città.

I modelli nella costruzione descrivevano decisioni tipiche testate nel tempo: quanto dovrebbero essere alte le finestre, quanti piani dovrebbero essere nell'edificio, quanta area nel microdistretto dovrebbe essere assegnata per alberi e prati.

Non sorprende quindi che nel 1994 sia stato pubblicato il libro “Techniques of Object-Oriented Design. Design Patterns”, che comprende 23 pattern che risolvono vari problemi di progettazione orientata agli oggetti.

Il libro è stato scritto da 4 autori: Erich Gamma, Richard Helm, Ralph Johnson e John Vlissides. Il titolo del libro era troppo lungo perché qualcuno lo ricordasse. Pertanto, presto tutti iniziarono a chiamarlo "libro della banda di quattro", cioè "libro di una banda di quattro" , e poi anche "libro di GoF".

E da allora sono stati scoperti altri modelli di design. L'approccio "pattern" è diventato popolare in tutte le aree della programmazione, quindi ora puoi trovare tutti i tipi di pattern al di fuori del design degli oggetti.

Importante! I modelli non sono soluzioni super originali, ma, al contrario, soluzioni tipiche e frequenti allo stesso problema. Buone soluzioni collaudate.

1.3 Elenco dei modelli

Molti programmatori non hanno imparato un solo schema in tutta la loro vita, il che, tuttavia, non impedisce loro di utilizzarli. Come abbiamo detto prima, i pattern sono buone soluzioni testate nel tempo e se il programmatore non è uno sciocco, allora con l'esperienza trova lui stesso tali soluzioni.

Ma perché, attraverso dozzine di prove ed errori, arrivare a soluzioni ottimali quando ci sono persone che sono già andate in questo modo e hanno scritto libri con la quintessenza della loro esperienza e saggezza di vita?

Puoi martellare un chiodo con una chiave inglese, ma perché? Puoi persino usare un trapano se ci provi. Ma un buon possesso consapevole dello strumento è proprio ciò che distingue un professionista da un dilettante. E il professionista sa che la caratteristica principale del trapano non è affatto in questo. Quindi, perché hai bisogno di conoscere i modelli?

• Soluzioni collaudate. Trascorri meno tempo utilizzando soluzioni standard invece di reinventare la ruota. Alcune decisioni potresti pensarle da solo, ma molte potrebbero essere una scoperta per te.
• Standardizzazione del codice. Fai meno errori di calcolo durante la progettazione, utilizzando le tipiche soluzioni unificate, poiché tutti i problemi nascosti in esse sono stati trovati da tempo.
• Dizionario generale di programmazione. Dici il nome del modello invece di passare un'ora a spiegare ad altri programmatori che bel design ti è venuto in mente e quali classi sono necessarie per questo.

Quali sono i modelli?

I modelli differiscono nel livello di complessità, dettaglio e copertura del sistema in fase di progettazione. Tracciando un'analogia con la costruzione, si può aumentare la sicurezza di un incrocio installando un semaforo, oppure si può sostituire l'incrocio con un intero interscambio automobilistico con sottopassaggi.

I modelli più semplici e di basso livello sono i modi di dire. Non sono universali, poiché sono applicabili solo nell'ambito di un linguaggio di programmazione.

I più versatili sono i modelli architettonici che possono essere implementati in quasi tutte le lingue. Sono necessari per progettare l'intero programma e non i suoi singoli elementi.

Ma la cosa principale è che i modelli differiscono nello scopo. I modelli con cui faremo conoscenza possono essere suddivisi in tre gruppi principali:

• I modelli di creazione si occupano della creazione flessibile di oggetti senza introdurre dipendenze non necessarie nel programma.
• I modelli strutturali mostrano modi diversi di costruire relazioni tra gli oggetti.
• I modelli comportamentali si occupano di una comunicazione efficiente tra gli oggetti.

1.4 Introduzione a UML

Cominciamo osservando gli stessi 23 schemi descritti nel libro Gang of Four. Sia i modelli stessi che i loro nomi sono cose familiari anche per un programmatore alle prime armi. Te li presenterò, ma consiglio vivamente di leggere proprio quel libro sui modelli.

I modelli di progettazione non sono legati a uno specifico linguaggio di programmazione, quindi l'UML viene solitamente utilizzato per descriverli. Era molto popolare 20 anni fa, ma anche adesso a volte viene usato. E a proposito, la descrizione dei modelli è solo il luogo in cui l'uso di UML è lo standard.

Con UML, puoi descrivere le relazioni tra diverse entità. Nel nostro caso, questi sono oggetti e classi.

Le relazioni tra le classi sono descritte da quattro tipi di frecce:

In effetti, qui è tutto molto semplice. L'ultima freccia in realtà significa che una classe è ereditata da un'altra classe. E la prima e la seconda freccia indicano che un oggetto memorizza un collegamento al secondo oggetto. Ed è tutto.

Se il diamante del collegamento è nero, il collegamento è debole: gli oggetti possono esistere l'uno senza l'altro. Se il rombo è bianco, allora gli oggetti sono fortemente correlati, come una classe HttpRequeste la sua classe figlio HttpRequest.Builder.

1.5 Elenco dei modelli

I tipi di motivi saranno indicati da diversi colori e lettere:

B- comportamentale (comportamentale);

C- generare (creativo);

S- strutturale (strutturale).

E infine, un elenco di 23 design pattern: