Quanto sono importanti i modelli di progettazione nella programmazione?

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?

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

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!

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.

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.

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!

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.

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.

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

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.