Sono uno studente universitario e ho appena iniziato a conoscere i modelli di design e sto lottando per comprenderne lo scopo. Ho provato a ricercarli ma tutte le risorse che ho trovato sembrano parlarne in un modo accademico, non professionale.
Qual è il loro scopo e sono importanti da imparare?
Gli schemi di progettazione sono ottimi per comunicare il tuo intento molto rapidamente: tutti sanno cos'è una fabbrica.
La cosa veramente brutta da fare veramente è iniziare a provare ad adattare il tuo codice ai pattern, o separare le responsabilità in base ai pattern o qualcosa del genere. Una cosa è dire "Questo oggetto è una fabbrica" e un altro per dire "Questo oggetto dovrebbe essere esclusivamente una fabbrica".
Dall'articolo di Wikipedia su Modelli di design :
The usefulness of speaking of patterns is to have a common terminology for discussing the situations designers already see over and over.
Per molto tempo abbiamo avuto un problema serio nell'ingegneria del software: assumi un nuovo arrivato in un progetto, e non importa quanto conoscano bene il linguaggio di programmazione, ci vogliono mesi per aggiornarsi su come vanno le cose fatto nel tuo progetto prima che possano essere produttivi. Nell'ingegneria dell'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, permetti loro di studiarli, e prima di sera è il momento di chiamarlo un giorno in cui possono prendere la pistola per saldare e diventare produttivi. Abbiamo cercato di trovare dei modi per migliorare in questo; la standardizzazione dei linguaggi di programmazione era un modo; le librerie standard (le librerie di classe al giorno d'oggi) sono state un altro modo; ma uno dei modi più importanti è forse stato il design pattern. Quindi, sono importanti? Ci puoi scommettere!
Esistono davvero due motivi diversi e sostanziali per l'esistenza di modelli.
Il primo è già stato spiegato abbastanza bene: l'uso di pattern lubrifica la comunicazione tra gli sviluppatori. Se entrambi capiamo che quando dico "Observer" sto parlando di una struttura di codice molto specifica, allora posso descrivere molto rapidamente come funziona un po 'di codice che usa quel modello. L'alternativa è descrivere completamente la soluzione, che richiede molto tempo ed è soggetta a errori. ("Beh, ho creato questa pura classe virtuale che descrive e interfaccia per oggetti di consumo, e quindi ho creato una classe che mantiene un elenco di consumatori attivi, che ...")
Il secondo vantaggio dei modelli è che si tratta di moduli di soluzioni 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 di produzione 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.
Anche questi vantaggi si rafforzano a vicenda. Ti permettono di risolvere rapidamente alcune classi comuni di problemi, e quando hai finito, puoi comunicare molto rapidamente come hai risolto il problema.
Confrontalo con un mondo in cui i pattern "non esistono". Ti imbatti in una di queste classi di problemi, che in genere non sono problemi di progettazione banali, e passi un bel po 'di tempo a trovare una buona soluzione (che, per inciso, molto probabilmente assomiglierà molto al modello appropriato). Poi, il tuo collaboratore si avvicina e vuole sapere come lo hai risolto, e passi un'ora a discutere del come e del perché.
Questo è tutto 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 si perderà il beneficio di riduzione dello sforzo dei modelli. Inoltre, poiché il tuo lavoro non si adatta più alla comprensione del significato del modello da parte dei tuoi collaboratori, perderai il costo dei benefici della comunicazione. In effetti, è probabile che aumenterai il costo della comunicazione oltre il costo no-pattern, perché l'uso improprio del modello darà ai tuoi colleghi una falsa comprensione della soluzione, che è peggio di nessuna comprensione.
I pattern 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 riuso di codice è una buona cosa - ma risulta essere più difficile di quanto ci piacerebbe fare praticamente (per certi versi questo sta cambiando, ma sarà sempre essere una sfida). Ma in realtà gran parte di ciò che vogliamo riutilizzare è un modo di fare le cose, di usare una sorta di template per costruire una soluzione a un particolare problema - questi sono Patterns. Quindi si arriva a un caso in cui si dice che un buon approccio alla risoluzione del problema X è l'uso di Pattern Y e sappiamo che gli elementi del pattern Y sono a, b e c e partiamo. Poiché gli schemi sono ampiamente compresi, non è necessario spiegare a fondo quale è il vantaggio della comunicazione.
Ciò che è interessante per i pattern è che le lingue e i framework si stanno evolvendo per fornire un migliore supporto per modelli comuni con l'effetto netto che stiamo ottenendo sempre più e meglio il riutilizzo del codice (più e lego meglio!) perché il modo in cui costruiamo applicazioni ( implementando i modelli) facilita il riutilizzo.
I modelli di progettazione sono solo mattoni noti su cui è stata costruita qualsiasi soluzione software. Sono importanti per i seguenti motivi:
Sono indipendenti dal linguaggio. Una volta che sai quale modello di progettazione è appropriato per determinati problemi / architettura / attività, puoi implementarlo in qualsiasi linguaggio multi-paradigma: sia C #, Java o Python - la soluzione nella maggior parte dei casi è la stessa, devi solo adattare la sintassi. Ciò significa che puoi trasferire la tua esperienza dalla programmazione in una lingua ad altre lingue, purché tu rimanga nello stesso dominio problematico (e forse anche tra i domini).
Nonostante il fatto che gli schemi di progettazione abbiano un legame con il paradigma di programmazione , significa che i modelli di progettazione per la programmazione orientata agli oggetti (i più famosi, noti anche come " Gang of Four "). I pattern ti consentono di capire a cosa serve il paradigma e ti aiutano ad andare oltre la sintassi. Ad esempio ho visto molte implementazioni in C # e Java dove le persone hanno appena programmato il modo in cui l'hanno fatto Basic o Fortran - hanno una mente imperativa perfetta per risolvere i problemi e usano OOP solo per rendere questa soluzione - nessuna ereditarietà, nessun polimorfismo, tutti i metodi sono pubblici, ecc. I pattern di progettazione ti aiutano a guardare dietro questi concetti e vedere come lavorare nella vita reale. Lo stesso vale per il modello di progettazione in altri paradigmi, come la programmazione funzionale.
I pattern sono generalmente un modo pratico per rappresentare le idee e sono approdati all'Informatica dall'architettura. Una volta che hai capito l'idea di un certo "pattern", puoi facilmente riconoscere questo pattern in qualche altro problema e risolverlo usando questo pattern (probabilmente leggermente modificato per meglio indirizzare il tuo problema). Esistono molti modelli diversi: in Integrazione software aziendale , in Test del codice sorgente ecc. Cerca solo modelli nei libri per l'Informatica.
Oltre all'acquisizione di buone pratiche mediante modelli di apprendimento puoi facilmente imparare come evitare errori stupidi nel tuo codice studiando anti-pattern . ci sono molti libri che presentano errori comuni in diversi domini sotto forma di anti-pattern che sono molto divertenti e educativi allo stesso tempo. Ad ogni modo, adoro i nomi di questi anti-pattern!
Puoi pensare a un modello come a un modo comprovato per risolvere un problema che tu e altri sviluppatori comprendete. Ad esempio, il problema è creare un elenco ordinato di dati, quindi è possibile scegliere di utilizzare un elenco collegato o inserire dati in un vettore e ordinarli. Probabilmente capisci entrambe le opzioni perché potresti già conoscere il modello di elenco collegato o il modello di vettore di caricamento e ordinamento. Potresti conoscere i pro e i contro di ciascuno e non è necessario vedere l'implementazione per capire cosa sta succedendo.
Penso che tu sia un antipasto 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 dello sviluppo del software. Dovresti essere più pratico nel codice e scoprire quale stile di codice è sbagliato e quindi apprendere modelli di progettazione per migliorare la progettazione.
L'utilità di un modello di progettazione dipende dalla lingua scelta. Il linguaggio più potente che scegli meno hai bisogno di capire e implementare schemi di progettazione. Un pattern di progettazione può essere un segnale per cui la tua lingua sucks non ha una funzionalità incorporata.
Joe Gregorio ha fatto un bel discorso a proposito la mancanza di schemi di progettazione in Python
I modelli di progettazione sono soluzioni ai problemi 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 fornendoti una serie di buone soluzioni a questi problemi comuni.
Leggi altre domande sui tag java design-patterns