I modelli di progettazione sono strumenti. Come gli strumenti, ci sono due modi per usarli: il modo corretto e il modo errato. Ad esempio, se ti do un cacciavite e un chiodo e ti chiedo di unire due pezzi di legno insieme, dovresti chiedermi un martello. I martelli sono usati per i chiodi, mentre i cacciaviti sono usati per le viti.
Troppo spesso, un modello di progettazione è pubblicizzato come One True Way, che è spesso vero solo quando sorgono problemi particolari. Gli sviluppatori junior sono spesso come bambini quando trovano qualcosa di nuovo con cui giocare; vogliono applicare quel modello di design a tutto . E non c'è nulla di intrinsecamente sbagliato in esso, finché alla fine imparano che il modello A si applica al problema B e il modello C si applica al problema D. Proprio come non si utilizza un cacciavite per guidare i chiodi, non si utilizza un particolare modello solo perché esiste; si utilizza il modello perché è lo strumento migliore (noto) per il lavoro.
Il rovescio della medaglia è rappresentato dagli anti-motivi. Cose che hanno dimostrato più volte di essere cattive, di solito in termini di tempo di esecuzione o memoria. Tuttavia, sia i pattern che gli anti-pattern non fanno bene allo sviluppatore che non capisce perché esistano. Agli sviluppatori piace pensare che ciò che stanno facendo sia nuovo e inventivo, ma il più delle volte non lo sono. Probabilmente è stato pensato prima. Le persone prima di loro hanno creato gli schemi grazie all'esperienza.
Ovviamente, gli sviluppatori junior sembrano spesso escogitare nuovi modi di fare cose vecchie, e talvolta quei modi sono migliori. Tuttavia, troppo spesso finisce per essere un caso dell'effetto Dunning-Kruger; lo sviluppatore sa quanto basta per creare un programma funzionale, ma non capisce i propri limiti. L'unico modo per superare questo sembra essere attraverso l'esperienza, sia positiva che negativa. Ignorano i modelli perché si credono superiori, ma non sanno che, in realtà, 10.000 sviluppatori hanno già utilizzato un design specifico e lo hanno scartato perché in realtà era un problema.
Agile preferisce "fare le cose in modo reattivo" per quanto riguarda l'adattamento rapido alle esigenze in evoluzione del cliente. Non favorisce i modelli di progettazione né li disprezza. Se un modello è il metodo più veloce e affidabile, lo sviluppatore dovrebbe utilizzarlo. Se un particolare schema costerebbe più tempo rispetto al semplice "completamento", è probabile che usare qualcosa che non sia un modello (supponendo, ovviamente, che le prestazioni non siano gravemente degradate, ecc.). Se non è possibile trovare alcun modello noto, è preferibile progettarne uno piuttosto che dire al cliente "no". I clienti, in particolare i clienti paganti, di solito hanno ragione.
Chiunque sostenga che i modelli siano La Via o che i modelli siano La rovina dell'esistenza, ha torto. I modelli sono strumenti, pensati per essere applicati a situazioni specifiche e hanno vari gradi di successo in base alle circostanze. Questa è una verità, che non dipende dal fatto che tu abbia scelto MVC o meno, se utilizzi gli oggetti Data Transfer o no, ecc. Ciò che conta è l'implementazione del codice in un intervallo di tempo ragionevolmente breve, che funziona ragionevolmente bene per gli utenti, ed è ragionevolmente privo di bug logici.
Di solito , i pattern consentiranno una forma coerente di design e avranno prestazioni migliori rispetto all'ignorare tutti i pattern a favore della scrittura di idee originali al 100%, ma non è possibile evitare tutti i pattern. Ad esempio, se y = x + 5, hai davvero intenzione di scrivere y = x + (5 * 3 + 15/3) / 4, solo per evitare lo schema di scrittura x + 5? No non siete. Scriverai y = x + 5 e passerai al problema successivo.
Le persone usano i modelli ogni giorno, e va bene . Ciò che conta di più è avere un codice logicamente funzionale, raramente si arresta in modo anomalo ed è intuitivo. Nient'altro conta più di questo.