Do Design Patterns Stifle Creativity

Il tuo professore di economia è assolutamente corretto.

I modelli di progettazione software sono principalmente un modo per esperti sviluppatori di software di comunicare tra loro . Sono una scorciatoia per soluzioni consolidate a problemi noti.

Ma dovrebbero essere usati solo da persone che capiscono come risolvere il problema senza il modello, o hanno escogitato un modello simile da soli. Altrimenti, avranno lo stesso problema del codificatore copia / incolla; avranno il codice, ma non capiranno come funziona e quindi non saranno in grado di risolverlo.

Inoltre, molti dei modelli di progettazione sono modelli enterprise , modelli che sono destinati a essere utilizzati in sistemi software aziendali di grandi dimensioni . Se si imparano le meraviglie di Inversion del container Control, lo si vorrà utilizzare in ogni programma che si scrive, anche se la maggior parte dei programmi non ne ha effettivamente bisogno (ci sono modi migliori per iniettare le proprie dipendenze in programmi più piccoli, in modo da non richiedere un contenitore IoC).

Impara i modelli. Comprendere i modelli e il loro uso appropriato. Sapere come risolvere lo stesso problema senza il pattern (tutti i pattern software sono astrazioni rispetto agli algoritmi fondamentali). Quindi sarai in grado di utilizzare schemi software con sicurezza, quando ha senso farlo.

Il modo in cui i modelli di progettazione che le persone vogliono che tu guardi a Design Patterns è un insieme di soluzioni che puoi applicare se emergono problemi simili. Non vogliono che tu pensi a loro come alle sole soluzioni possibili, date da Dio a Mosè intagliato in tavolette di pietra sulla montagna.

Sfortunatamente, alcune persone li considerano come qualcosa di più vicino alla scrittura sacra piuttosto che a un mucchio di esempi di design da cui imparare. Ciò uccide la creatività e crea un culto del carico.

Il tuo professore di economia ha menzionato di aver presentato agli studenti il problema e di aver cercato di risolverlo prima, che è una buona tecnica educativa, ma ha avuto una soluzione per mostrarli. Avere un sacco di soluzioni a molti problemi diversi nella tua testa è una buona cosa, ed è qualcosa che Design Patterns cerca di essere. Penso che fallisca in qualche modo (Singleton incoraggiando approcci sbagliati, un focus miope sull'imperativo OO, ecc.), Ma potrebbe essere usato bene con intelligenza e gusto. Tuttavia, è un errore pensare che ogni possibile soluzione di esempio nel software deve essere un modello di progettazione ufficiale.

Se guardi un problema e ti chiedi "Qual è il modello di progettazione per questo?", allora stai sbagliando, e avrai meno probabilità di vedere una soluzione che ti sta fissando in faccia.

Se guardi un problema e ti chiedi "Come posso risolvere questo?", quindi se c'è una soluzione non-pattern, lo vedrai, e se c'è un modello che si adatta, lo vedrai anche tu .

Penso anche che il tuo professore di economia sia corretto e che sia un modo per imparare qualcosa in primo luogo; Diamo comunque un'occhiata a questo: manterrai il Wheel segreto e lascerai che tutti lo reinventino, per il bene di Creatività ? Mi aspetto che tu dica No, perché non tutte le persone sono fatte / capaci di inventare le loro ruote - e se lo sono, lo faranno a un certo punto, non importa se sono a conoscenza dell'esistenza della ruota o no.

Torniamo ai programmatori; Sono uno sviluppatore web di giorno, quindi MVC è una di quelle cose con cui interagisco quotidianamente. Diverse volte ho cercato di costruire le mie strutture, ho imparato molto ma tutte erano fondamentalmente infruttuose. Ho fatto del mio meglio, ma cosa succederebbe se non ci fossero MVC là fuori? Bene, semplice, il mio codice sorgente fa schifo - in termini di affidabilità, manutenibilità ed estendibilità.

Penso che sia lo stesso per la maggior parte di noi. Se nessuno ti parla di DI - come buona pratica, allora quante applicazioni aziendali devono lottare o fallire finché i loro sviluppatori non imparano la lezione?

Il secondo punto è Standard di settore . Se non insegni MVC a sviluppatori web, sei pronto ad affrontare tutte quelle strutture non standard di cui hai bisogno per passare un po 'di tempo a imparare il loro modo di fare le cose prima, e poi ti rendi conto che alcune di quelle strutture potrebbero avere una buona idea, ma la maggior parte di essi avrà seri difetti di progettazione che potrebbero avere serie conseguenze per il tuo progetto software - anche le strutture ben note hanno ancora problemi di progettazione ogni tanto.

Ma cosa succederebbe se avessimo tutte quelle belle idee e le mettessimo tutte insieme e quegli sviluppatori intelligenti prendessero le cose buone da tutti quegli esperimenti e realizzassero una struttura davvero interessante che funzioni meglio per quel problema specifico? Quindi hai appena creato Design Patterns . Se sei una creatura vivente, allora non c'è altro modo; Persino gli animali seguono le migliori pratiche e i modelli di progettazione nella loro vita quotidiana.

Non reinventare un martello, ma non trattare ogni problema come un chiodo

I modelli di programmazione sono un ottimo risparmio di tempo, perché ti offrono soluzioni pronte all'uso, ben documentate e testate con casi medi che potresti facilmente dimenticare. Ma devi imparare (e pensare) quando usarli.

Parafrasando la tua domanda: imparerebbe a guidare a farmi muovere più velocemente, o semplicemente a camminare più lentamente?

Imparare a usare schemi di programmazione non significa che non si dovrebbe esercitare la ricerca di soluzioni proprie. Ci saranno ancora abbastanza problemi per esercitare la tua creatività. Conoscere i modelli di programmazione ti permetterà solo di essere veloce con problemi noti e di concentrarti su quelli, che sono meno banali.

Ritornando alla seconda parte della domanda - il tuo proffesor ha ragione?

Sì, ha ragione . L'obiettivo principale degli studi è quello di imparare a pensare agli studenti . Devono cercare di trovare le proprie soluzioni al problema e quindi confrontarle con le soluzioni esistenti. Solo in questo modo possono davvero comprenderli. Se impari prima i modelli, rischi di imparare solo meccanicamente ad applicarli, e non a capire, cosa c'è dietro.

Questa è la ragione per cui insegni agli studenti a programmare e i modelli sono introdotti in ulteriori semestri.

Vorrei assolutamente evitare di insegnare la programmazione insegnando modelli di progettazione. Non puoi applicarle bene senza comprendere i principi che stanno dietro di esse, quindi insegnare questi principi è molto più importante.

Tendo a pensare che i modelli di design non siano davvero tanto preziosi per i programmatori che lavorano, comunque. Se comprendi pienamente i principi implicati in un determinato modello di progettazione, allora in una situazione in cui è una buona soluzione, naturalmente tenderai a costruirlo (o qualcosa di simile) in ogni caso, naturalmente, anche se non lo sapevi che era uno schema con un nome. Qualunque sia il tempo che trascorrerai, i pattern di apprendimento potrebbero essere spesi meglio imparando a pensare al codice in generale. Se le tue abilità di "problem solving in generale" non sono all'altezza, allora non puoi scrivere un buon codice, non importa quanto sei bravo nell'applicare una serie di modelli. E se le tue abilità di "problem solving in generale" sono buone, puoi risolvere i problemi anche se non conosci un singolo pattern.

Penso anche che in un mondo ideale non ci sarebbe essere nessun modello di design, perché le idee abbastanza comuni da essere definite pattern sarebbero tutte ben implementate nelle biblioteche e in realtà saremmo riutilizzare il codice anziché costantemente riscriverlo . Immagina se esistesse un "pattern di progettazione di espressioni regolari", che richiedesse di implementare un piccolo motore regex ogni volta che volevi usarlo. I modelli di progettazione sono solo librerie che non possono essere scritte perché la lingua non fornisce le giuste strutture di astrazione.

Questa è in realtà un'altra ragione per cui non ci importa molto di loro; non sono affatto vicini come universali come talvolta si afferma, ma sono in realtà strettamente legati alle modalità particolari di strutturazione dei programmi che un particolare linguaggio consente / incoraggia. Un libro di disegni di design scritto per Python sarebbe completamente diverso da uno scritto per Java, e persino più diverso da uno scritto per un linguaggio non imperativo come Haskell. È meglio capire a un livello più profondo e sarai in grado di scoprire modelli di design in qualsiasi lingua con cui acquisisci familiarità.

Il commercio e l'istruzione hanno obiettivi diversi. Se insegnassi agli studenti schemi di progettazione, adotterei lo stesso approccio. Ma in un ambiente di produzione, il tempo e l'efficienza sono tutto.

Inoltre, l'economia (macro) al di fuori della classe è una cosa diversa. Vedete i governi dire, "Whoa! Ora siamo super annoiati a fare le tasse e allo stesso modo, quindi proviamo qualcosa di super stravagante questa volta"? No, non lo fai, perché tali esperimenti selvaggi possono distruggere l'economia irreparabilmente. Invece, tendono ad attenersi a approcci collaudati: aumentare il tasso di interesse, annunciare festività fiscali, ecc. In altre parole, si basano su modelli di design.

La risposta è, naturalmente: Sì.

I modelli di design sono un meraviglioso strumento di apprendimento in sé, a patto che ci si dedichi a capire come funzionano e perché portano il valore che portano.

Possono anche essere ottimi incentivi di produttività grazie al monitoraggio rapido di un processo di progettazione, poiché forniscono soluzioni familiari ai problemi che si verificano continuamente.

Tuttavia, se progettano troppo il cortocircuito o le persone diventano dogmatiche e troppo precise sul loro uso, allora hanno l'effetto opposto.

I modelli di design sono ovviamente meno creativi. Questa è l'idea. La creatività è una risorsa scarsa. Non dovresti sprecarlo per problemi che non richiedono creatività. È molto più facile, più veloce e più probabile che funzioni, se risolvi un problema nello stesso modo di centinaia di sviluppatori prima di te. Il codice noioso e poco eccitante che fa il suo lavoro è effettivamente buono.