Quanto sono importanti i modelli di progettazione nella programmazione?


19

Sono uno studente universitario e ho appena iniziato a conoscere i modelli di progettazione e sto lottando per comprenderne lo scopo. Ho provato a ricercarli, ma tutte le risorse che ho trovato sembrano parlarne in modo accademico, non professionale.

Qual è il loro scopo e sono importanti da imparare?


7
Sono utili per le interviste di lavoro!
wim

5
Un modello di progettazione è solo un modo comunemente ricorrente per risolvere i problemi. Di solito derivano da carenze nelle lingue.
Jon Purdy,

7
Comprendere lo scopo dei modelli di progettazione richiede la comprensione dei problemi che risolvono. Comprendere questi problemi richiede esperienza nel farlo nel modo più duro :)
MattDavey,

Risposte:


36

I modelli di progettazione sono perfetti per comunicare molto rapidamente le tue intenzioni: tutti sanno cos'è una fabbrica.

Ciò che è veramente, molto, molto brutto da fare è iniziare a cercare di adattare il codice a schemi o separare le responsabilità in base a schemi o qualcosa del genere. Una cosa è dire "Questo oggetto è una Fabbrica" ​​e un'altra dire "Questo oggetto dovrebbe essere esclusivamente una Fabbrica".


1
Quindi siete tutti per motivi ma non sono realmente per il vostro codice. Sì, sono bravi a comunicare l'idea, ma sono anche migliori quando puoi vedere lo schema nel codice reale.
Newtopian,

3
Perché votare male? Questa è in realtà la migliore risposta IMHO. La codifica è di buon senso e talvolta è possibile utilizzare rapidamente uno schema adatto per risolvere il problema. Ma una volta che le persone iniziano ad abusare di loro ovunque, si trasforma in un casino infernale.
Coder

1
Ogni codice contiene alcuni pattern, anche se non ne sei consapevole. I motivi di design di cui stai parlando si raggruppano e nominano un insieme di motivi ampiamente utilizzati e utili. Quando li conosci, puoi pensarci in un modo più consapevole. Se chiami una delle tue classi "ControlDispenser", probabilmente nessuno saprà cosa dovrebbe fare. Tuttavia, se conosci il modello di fabbrica, lo chiamerai "ControlFactory" e altri lo capiranno immediatamente.
Olivier Jacot-Descombes,

4
Se serve a un altro scopo, dovrebbe essere un'altra classe ... separazione delle preoccupazioni.
Nate,

2
@Nata: uno scopo può essere diversi schemi. Non c'è motivo per cui una classe debba coinvolgere solo un modello. Gli schemi non sono responsabilità "atomiche". Una singola responsabilità può richiedere diversi schemi.
DeadMG

26

Dall'articolo di Wikipedia su Design Patterns :

L'utilità di parlare di schemi è avere una terminologia comune per discutere le situazioni che i progettisti già vedono più e più volte.

Per molto tempo abbiamo avuto un serio problema nell'ingegneria del software: assumi un nuovo arrivato a un progetto, e non importa quanto sappiano bene il linguaggio di programmazione, ci vogliono mesi per aggiornarsi su come vengono fatte le cose nel tuo progetto prima che possano essere produttivi. In ingegneria hardware, hanno risolto questo problema molto tempo fa: hanno una terminologia comune chiamata "diagrammi schematici". Assumi un ingegnere hardware, dai loro gli schemi del tuo progetto hardware al mattino, lasciali studiare, e la sera prima che sia il momento di chiamarlo un giorno possono prendere la pistola per saldare e diventare produttivi. Abbiamo cercato di trovare modi per migliorarci; la standardizzazione dei linguaggi di programmazione era un modo; le librerie standard (librerie di classe al giorno d'oggi) sono state un altro modo; ma uno dei modi più importanti è forse stato il design. Quindi sono importanti? Scommetti!


3
Il confronto tra lo sviluppo del software e l'ingegneria elettrica è accurato quanto il confronto tra un razzo di Saturno e una bicicletta. Entrambi i metodi di trasporto (passando dal punto A al punto B), ma procedono in modi completamente diversi e non compatibili.
Jer

3
@jer Hmmm, la tua analogia è scarsa. Entrambi sono discipline ingegneristiche. Anche se le loro somiglianze finissero lì, avrebbero ancora, per definizione, molto in comune. Non speriamo di identificarli mai, ma uno ha molto da imparare dall'altro.
Mike Nakis,

6
@ Mike: non è una differenza fondamentale: circuiti elettrici sono vincolati da limiti fisici duri. I sistemi software sono vincolati dai limiti fuzzy dell'intelletto umano.
Kevin Cline il

3
Prima di tutto, non ho detto che non ci sono grandi differenze. In secondo luogo, neanche la tua affermazione è corretta. Il software obbedisce a forti vincoli, quelli stabiliti dalla sintassi di una lingua. E anche il numero di permutazioni in cui l'intelletto umano può interconnettere i componenti elettronici è illimitato. Ma ancora una volta, non sto cercando di equiparare i due, o anche di dire che c'è una tremenda somiglianza. Sto solo dicendo che l' uno ha molto da imparare dall'altro .
Mike Nakis,

3
Poiché il software riguarda la progettazione, un'analogia analoga di ingegneria elettrica sarebbe la discussione di "mirror corrente" e "feedback negativo" in un circuito amplificatore. Questi non sono componenti discreti su uno schema, ma piuttosto una disposizione di più componenti che soddisfa un determinato scopo. Saper connettere i componenti senza conoscerne gli scopi non consentirà a una nuova persona di realizzare un nuovo design. (cioè è un passo avanti nella comprensione.)
rwong

9

Vi sono in realtà due ragioni diverse e sostanziali per l'esistenza di schemi.

Il primo è già stato spiegato abbastanza bene: l'uso di modelli lubrifica la comunicazione tra gli sviluppatori. Se entrambi capiamo che quando dico "Osservatore" sto parlando di una struttura di codice molto specifica, allora posso descrivere molto rapidamente come funziona un po 'di codice che utilizza quel modello. L'alternativa è descrivere in modo completo la soluzione, che richiede tempo ed è soggetta a errori. ("Bene, ho creato questa pura classe virtuale che descrive e si interfaccia con gli oggetti di consumo, e poi ho creato una classe che mantiene un elenco di consumatori attivi, che ...")

Il secondo vantaggio dei modelli è che sono moduli di soluzione standard per moduli di problemi comuni. Se conosci i tuoi schemi e, ad esempio, incontri un problema in cui devi trovare un buon modo per ottenere informazioni da (possibilmente più) oggetti del produttore a più oggetti di consumo, senza introdurre un accoppiamento non necessario tra le classi, riconoscerai "questo è un lavoro per un osservatore! " e saprai immediatamente come risolvere il tuo problema.

Questi vantaggi si rafforzano davvero a vicenda. Ti consentono di risolvere rapidamente alcune classi comuni di problemi e, quando hai finito, puoi comunicare molto rapidamente come hai risolto il problema.

In contrasto con un mondo in cui i modelli "non esistono". Ti imbatti in una di queste classi di problemi, che in genere non sono banali problemi di progettazione, e passi un bel po 'di tempo a trovare una buona soluzione (che, per inciso, molto probabilmente assomiglierà molto al modello appropriato). Quindi, il tuo collega si avvicina e desidera sapere come l'hai risolto e passi un'ora a discutere di come e perché.

Tutto questo è associato a un avvertimento che dovrebbe sembrare abbastanza ovvio: non cercare di forzare i problemi in schemi che non si adattano. Se il modello non si adatta al problema, la soluzione finirà per essere contorta e perderai il beneficio di riduzione dello sforzo dei modelli. Inoltre, poiché il tuo lavoro non si adatterà più alla comprensione del significato del modello da parte dei tuoi colleghi, perderai il costo del vantaggio comunicativo. In effetti, probabilmente aumenterai il costo della comunicazione oltre il costo senza schemi, perché l'uso improprio dello schema darà ai tuoi colleghi una falsa comprensione della soluzione, che è peggio di nessuna comprensione.


2
È un'idea sbagliata che i modelli di progettazione siano una soluzione standard. Sono "MOTIVI" che non sempre si traducono in codice.
Martin York,

Ehm, un modello si traduce sempre in codice, questo è praticamente un dato di fatto - il problema è che potrebbero non adattarsi sempre al codice che hai o all'architettura che hai o ai vincoli su cui stai lavorando. vale a dire solo perché un modello può adattarsi che non significa necessariamente che puoi usarlo. Si potrebbe presumere che sia ciò che intendevi (ma non mi piace fare ipotesi).
Murph,

5

I modelli riguardano il riutilizzo di idee e concetti e la creazione di una piattaforma comune / coerente per la comunicazione degli stessi.

Siamo tutti d'accordo (!) Che in teoria il riutilizzo del codice è una buona cosa - ma risulta essere più difficile di quanto vorremmo farlo praticamente (per alcuni aspetti questo sta cambiando, ma sarà sempre una sfida ). Ma in realtà molto di ciò che vogliamo riutilizzare è un modo di fare le cose, di usare una sorta di modello per costruire una soluzione a un problema particolare: questi sono Pattern. Quindi si arriva a un caso in cui si dice che un buon approccio per risolvere il problema X è usare il modello Y e sappiamo che gli elementi del modello Y sono a, bec e così via. Poiché i modelli sono ampiamente compresi, non è necessario spiegare in modo approfondito quale sia il vantaggio della comunicazione.

La cosa divertente dei pattern è che linguaggi e framework si stanno evolvendo per fornire un supporto migliore ai pattern comuni con l'effetto netto che stiamo ottenendo un riutilizzo del codice sempre maggiore (legni sempre più lego!) Perché il modo in cui costruiamo le applicazioni (implementando i pattern ) facilita il riutilizzo.


4

I modelli di progettazione sono solo mattoni noti su cui si basa qualsiasi soluzione software. Sono importanti per i seguenti motivi:

  1. Sono agnostici del linguaggio. Una volta che sai quale modello di progettazione è appropriato per un dato problema / architettura / compito, puoi implementarlo in qualsiasi linguaggio multi-paradigma - lascia che sia C #, Java o Python - la soluzione sarà nella maggior parte dei casi la stessa, hai solo per adattare la sintassi. Ciò significa che puoi trasferire la tua esperienza dalla programmazione in una lingua ad altre lingue purché rimanga all'interno dello stesso dominio problematico (e forse anche tra domini diversi).

  2. Nonostante il fatto che i modelli di progettazione abbiano un legame con il paradigma di programmazione , il che significa che i modelli di progettazione per la programmazione orientata agli oggetti (i più famosi, noti anche come modelli "Gang of Four" ). I pattern ti consentono di capire a cosa serve il paradigma e ti aiutano ad andare oltre la semplice sintassi.Ad esempio ho visto molte implementazioni in C # e Java in cui le persone hanno appena programmato il modo in cui lo hanno fatto in Basic o Fortran - hanno una mente imperativa perfetta per risolvere i problemi e usano OOP solo per rendere questa soluzione - nessuna eredità , nessun polimorfismo, tutti i metodi sono pubblici, ecc. I modelli di progettazione ti aiutano a guardare dietro questi concetti e vedere come funzionano nella vita reale. Lo stesso vale per il modello di progettazione in altri paradigmi, come la programmazione funzionale.

  3. I modelli sono generalmente un modo utile per rappresentare idee e sono arrivati ​​all'Informatica dall'architettura. Una volta che hai compreso l'idea dietro un certo "modello", puoi facilmente riconoscere questo modello in qualche altro problema e risolverlo usando questo modello (probabilmente leggermente modificato per affrontare meglio il tuo problema). Esistono moltissimi schemi diversi: in Enterprise Software Integration , in Source Code Testing ecc. Basta cercare schemi nei libri per Computer Science.

  4. Oltre ad acquisire buone pratiche attraverso l'apprendimento di schemi , puoi facilmente imparare come evitare sciocchi errori nel tuo codice studiando gli anti-schemi . Ci sono molti libri che presentano errori comuni in diversi settori sotto forma di anti-schemi che sono molto divertenti e allo stesso tempo educativi. Adoro i nomi di questi anti-schemi, a proposito!


2

Puoi pensare a un modello come un modo comprovato per risolvere un problema che tu e altri sviluppatori capite. Ad esempio, il problema è creare un elenco ordinato di dati, quindi è possibile scegliere di utilizzare un elenco collegato o inserire i dati in un vettore e ordinare. Probabilmente capisci entrambe queste opzioni perché potresti già conoscere il modello di elenco collegato o caricare e ordinare il modello vettoriale. Potresti conoscere i pro e i contro di ciascuno e non avere bisogno di vedere l'implementazione per capire cosa sta succedendo.


1

Penso che tu sia un principiante per la programmazione, non ti suggerisco di imparare presto il modello di progettazione. L'apprendimento e la comprensione del modello di progettazione devono basarsi sull'esperienza di sviluppo del software. Dovresti essere più pratico nel codificare e trovare quale stile di codice è errato e quindi imparare il modello di progettazione per migliorare il design.


1

L'utilità di un modello di progettazione dipende dalla lingua scelta. Più linguaggio potente scegli, meno avrai bisogno di capire e implementare schemi di progettazione. Un modello di progettazione potrebbe essere un segnale che la tua lingua fa schifo manca di una funzione integrata.

Joe Gregorio ha fatto un'ottima chiacchierata sulla mancanza di modelli di progettazione in Python


Grazie per il link sulla mancanza di modelli di progettazione in Python. Modifica: Oops !! Il video è stato rimosso da quella posizione !! :(
Saurabh Patil,

0

I modelli di progettazione sono soluzioni ai problemi più comuni riscontrati nello sviluppo del software. C'è sempre più di una soluzione ad alcuni problemi e i modelli di progettazione ti aiutano a decidere quale soluzione è la migliore fornendo una serie di buone soluzioni a questi problemi comuni.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.