Per progettare il modello, o non progettare il motivo [duplicato]

Design patterns are good, but complex.

Questa è una falsa ipotesi. I Pattern di progettazione hanno lo scopo di eliminare la complessità dal codice esistente e di aiutare la comunicazione tra gli sviluppatori. Quando Design Patterns introduce un grado più elevato di complessità, vengono utilizzati in modo improprio.

Implementing design patters need more sophisticated developers and which in turn raises project costs.

Anche questo è un falso presupposto. Qualsiasi sviluppatore dovrebbe cercare di ottenere una quantità minima di complessità nel suo codice. Un buon sviluppatore vale i suoi soldi in quanto diminuiscono i costi di manutenzione ed estensibilità.

Are they necessary for small projects?

Sono necessari quando aiutano a rendere il codice più espressivo e meno complesso. Questo è indipendente dalla dimensione del progetto. Un buon sviluppatore (tm) non lo sovrastimerà e li userà quando appropriato.

Prima di tutto, segnalerò un ottimo post su programmers.stackoverflow.com: I modelli di progettazione sono per la comunicazione . Innanzitutto, offrono agli sviluppatori un linguaggio comune per parlare di tipici artefatti di progettazione / codice che emergono da qualsiasi sforzo di progettazione.

Sulle specifiche della tua domanda:

• I modelli di design sono buoni: False presupposti. I modelli di progettazione sono neutri, alcuni sono meno applicabili di altri e alcuni sono IMHO quasi antipattern a se stanti (singleton)
• I modelli di progettazione sono complessi: False presupposti. Alcuni schemi di progettazione sono in realtà molto semplici, come il modello di metodo del modello. Alcuni sono molto complessi, come lo schema del visitatore. In media gli schemi semplici hanno più usi di quelli complessi.
• Dovremmo utilizzarli in piccoli progetti? Quanto piccolo è piccolo? Ancora una volta IMHO il progetto dovrebbe essere estremamente piccolo per essere ben progettato e tuttavia non includere alcun modello di design riconoscibile. Potrebbe non includere molti, e quasi certamente salterà alcuni dei modelli strutturali o comportamentali più complessi come il visitatore o la catena di responsabilità.
• L'implementazione dei modelli di progettazione richiede sviluppatori più sofisticati: parzialmente veri per i pattern più complessi, ma assolutamente non per tutti i pattern, e ancora di più per i tipi di pattern che potresti utilizzare in progetti più piccoli
• Aumenta i costi del progetto: categoricamente non vero se i pattern sono applicati correttamente. Ciò che può far aumentare il costo del tuo progetto è la mancanza di design, cattiva progettazione o modelli di design applicati in modo errato / eccessivo.
• Rendono il codice pulito e ordinato: tutto il codice migliore in quanto è ordinato e pulito come potrebbe essere fatto, questo non è esclusivo per l'applicazione intenzionale dei modelli di progettazione.
• Sono necessari per i piccoli progetti: dipende dal tuo progetto. Se riesci a farla franca con il codice che soddisfa il suo scopo ma è molto difficile da mantenere, va bene. Tuttavia, se la manutenzione è probabile (ed è quasi una certezza in tutti i progetti su cui ho lavorato), il costo risparmiato in anticipo non considerando i modelli o il progetto nel suo insieme sarà ripagato abbastanza rapidamente in termini di dolore e durata extra durante la manutenzione.

La risposta di Falcon è giusta, ma volevo anche aggiungere altre informazioni.

Recentemente ho appreso (entro l'anno - anno e mezzo) schemi di progettazione. All'inizio, sono diventati il mio martello "d'oro" per tutti i problemi. Mi sono appena reso conto di aver sovra-ingegnerizzato molte delle applicazioni che ho sviluppato. Recentemente, mi è stato assegnato il compito di aggiungere funzionalità aggiuntive a un software che ho scritto, ma quando l'ho guardato, ho riflettuto sulla complessità che ho creato. Era perché, all'epoca, ero nel pieno della mia euforia di design pattern e stavo facendo ragionamenti per usare le mie nuove conoscenze. Questo non è il modo in cui avrebbe dovuto essere affrontato. Ora finisco per progettare i miei progetti con la semplicità in mente, più o meno ignorando i modelli di progettazione a meno che non ci sia un motivo molto chiaro per portarli. Questo di solito si presenta durante il processo di ri-factoring (almeno per me). / p>

I modelli di progettazione consentono inoltre agli sviluppatori di condividere un linguaggio comune. Quando ogni sviluppatore conosce la lingua, puoi spiegare molto facilmente ampie sezioni di codice.

Stai sempre usando una sorta di schema. L'unica differenza è se il tuo modello è il più semplice possibile o meno. Il codice dietro il codice degli spaghetti e delle polpette segue un modello, sembra essere un modello orribilmente difficile da comprendere, perché mette tutto in un unico posto (chi vuole lavorare con il codice che contiene frammenti SQL, manipolazioni dell'interfaccia utente e logica aziendale tutto in uno metodo). Ricorda che qualsiasi idiota può scrivere un software progettato in modo orribile, ma solo un genio (probabilmente costoso) può tornare indietro e risolvere il problema in un secondo momento.

Per rispondere a una parte specifica della tua domanda:

Implementing design patters need more sophisticated developers and which in turn raises project costs.

Penso che tu stia fraintendendo qual è il buon design. Pensaci; È più facile capire un algoritmo con 5 nesting deep loop o uno con 2 deep looping? Quale sarebbe la scelta più economica? La 2 scelta profonda è più facile da leggere, scrivere, mantenere e capire. Allora, perché stai cercando di giustificare il 5 loop profondo? Il cosiddetto "modello di progettazione" è il modello più semplice ogni volta, per definizione. Se i tuoi sviluppatori non sono in grado di scrivere software ben progettato (ovvero: il tipo più redditizio), devi trovare sviluppatori che possano comprendere la programmazione abbastanza bene da prendere decisioni di progettazione di base.

Dipende non dalle dimensioni del tuo progetto ma dal problema che stai cercando di risolvere. Utilizzare un modello di progettazione per il gusto di usarlo è una brutta cosa negativa, che si tratti di un progetto di piccole / medie / grandi dimensioni. D'altra parte, se implementando un modello di progettazione, risolvi un problema particolare, allora questo è l'atteggiamento giusto e la cosa interessante, indipendentemente dalle dimensioni del progetto. È l'intento che è importante.

Dovresti sempre utilizzare modelli di design, se non altro perché sei un buon programmatore. Non dovresti partire per usarli, comunque. Se il tuo progetto è valido, è probabile che avrai utilizzato diversi schemi di progettazione (al contrario, se il tuo design è scadente, potresti iniziare a riconoscere gli anti-pattern). Respingo la tua affermazione secondo cui i modelli di progettazione sono complessi. Scaricarli inutilmente sarà complesso, ma usarli correttamente - vale a dire come maniglie convenienti per comunicare parti di un progetto e analizzarne i punti di forza e di debolezza - non lo è.

Pensa ai modelli di progettazione come al vocabolario comune per sviluppatori e progettisti di software. Immagina uno sviluppatore che ti dice

Ho mantenuto il costruttore della mia classe di connessione come privato e ho invece dato un metodo pubblico getInstance dove ho messo un controllo che non è possibile effettuare più connessioni N

invece di

La mia classe di connessione è singleton con max istanze

la seconda riga è meno di 1/3 del primo. Immagina le parole che salverai quando userai modelli come Factory.

Stavo per commentare l'eccellente risposta di Falcon, ma ho avuto troppo da dire per usare un commento.

 Design patterns are good, but complex.

Come altri hanno notato, il codice ben scritto utilizzerà schemi di progettazione, anche se non implementati intenzionalmente. I modelli di progettazione sono osservati, non inventati. Più semplici i modelli di progettazione tendono ad adattarsi a più casi.

I pattern di progettazione complessi sono soluzioni a problemi complessi. Spesso è meglio usare lo schema di progettazione appropriato piuttosto che inventare la propria soluzione complessa.

Allineare un problema a un motivo di progettazione in un anti-pattern. Se il modello non si adatta al problema, non dovrebbe essere usato.

Implementing design patterns need more sophisticated developers 
and which in turn raises project costs. 

Gli sviluppatori più sofisticati possono arrivare a un salario più alto. Tuttavia, dovrebbero venire con una maggiore produttività. C'è stata una ricerca che mostra enormi differenze di produttività tra i programmatori. Pagheresti il 50 percento in più da qualcuno quattro o cinque volte più produttivo?

Gli sviluppatori più sofisticati hanno meno probabilità di introdurre bug costosi nel tuo software. Ciò ridurrà i costi di test, oltre a ridurre la rilavorazione per rimuovere i bug.

Il loro codice sarà in genere più semplice e più economico da mantenere nei casi in cui vengono rilevati errori o è necessario estendere la funzionalità.

On the other hand, they make code neat and clean.

I modelli di progettazione sono uno dei numerosi strumenti che renderanno il tuo codice pulito e ordinato. Offrono anche soluzioni comprovate a problemi comuni. Ci saranno molte opportunità sulla maggior parte dei progetti per usare l'inventiva su problemi che non si adattano a modelli di design ben noti.

Solo per essere pedante, mentre riconoscere i Pattern di progettazione rende più facile capire cosa fa il codice, i pattern stessi non "make code neat and clean" . È più probabile che i pattern rendano il codice più disordinato e quindi più difficile da capire se vengono implementati con poca riflessione o comprensione su come applicarli.

I pattern non sono un proiettile d'argento. Non risolveranno i tuoi problemi per te e ti preoccuperanno molto se stai usando il "giusto schema", o se puoi ricordare che ogni singolo pattern nel libro GoF non ti renderà un programmatore migliore. D'altra parte, la comprensione del linguaggio dei Pattern ti consentirà di articolare in modo più chiaro idee e progetti in modo significativo.

I modelli di progettazione sono solo strumenti che consentono di definire e risolvere i problemi nel contesto del codice. Se provi a utilizzare molti schemi semplicemente perché pensi di dover utilizzare schemi, finirai per sovradimensionare i problemi relativamente semplici. Ad esempio, puoi introdurre un pattern Observer completo per ogni evento che innalzi nel tuo codice, ma se il tuo codice è l'unica cosa che attiverà quegli eventi e se si prevede che gli eventi attiveranno solo un singolo handler, allora Non è necessario creare osservatori per svolgere il lavoro, mentre assegnare un semplice puntatore a una proprietà e il codice per attivarlo probabilmente andrà altrettanto bene. Se pensi che "potresti" aver bisogno del tuo Observer in futuro, allora "potrebbe" valere la pena di ingegnerizzarlo. Rischiate di rendere il vostro codice a prova di futuro senza capire veramente se ne varrà la pena, e il risultato sarà spesso come la placcatura dell'oro quando una spruzzata di vernice gialla sarebbe stata più appropriata.

I pattern spesso risolvono problemi molto specifici, e sono altrettanto abusati semplicemente perché sono un adattamento vicino ma imperfetto per il problema in questione. A volte può essere meglio vedere un modello emergere dal codice e utilizzare la conoscenza dei modelli per aiutarti a capire meglio come affrontare il problema. A volte può accadere che un pattern faccia esattamente il lavoro, ma altre volte è meglio prendere le idee dietro un pattern, ma implementare una versione modificata del pattern per risolvere il tuo particolare problema.

Tutto ciò sembrerebbe indicare che il linguaggio dei Pattern è probabilmente uno strumento più importante per lo sviluppatore rispetto ai singoli pattern stessi.

Una comprensione di base e il riconoscimento di schemi di progettazione creazionali, comportamentali e strutturali standard possono solo aumentare la comprensione di OOD degli sviluppatori e conferire loro la capacità di comunicare concetti complessi con meno parole.

Inoltre, la conoscenza dei modelli di concorrenza può semplificare la vita quando si ha a che fare con l'esecuzione di thread. Più facile non è più difficile!

La comprensione dei modelli offre inoltre agli sviluppatori una serie di soluzioni pronte per problemi di progettazione software molto comuni. Raccomanderei invece di pensare ai pattern come a un'abilità da usare o non usare, considerali come un vantaggio che uno sviluppatore dovrebbe sfruttare.