I pattern di progettazione sono essenziali per un buon codice? [duplicare]

Non sono richiesti schemi di progettazione per scrivere un buon codice.

Sono nomi dati a determinate soluzioni note per problemi di programmazione comuni. È probabile che tu abbia effettivamente utilizzato alcuni modelli di progettazione senza sapere (ad esempio, il pattern iteratore è incorporato in più lingue in quanto è così prevalente).

Conoscere i nomi e i significati dei modelli di progettazione è semplicemente un aiuto alla conversazione professionale (e alla denominazione di variabili e metodi) - quando tu e l'altra parte conoscete i modelli di progettazione, è più chiaro cosa sta succedendo.

Ciò che non dovresti fare è cercare modi per implementare uno schema di design specifico - dovresti guardare nella direzione opposta - trovare i pattern già esistenti nel codice e, facoltativamente, rinominare il codice se lo rendono più chiaro.

Quindi, non devi studiare o conoscere i modelli e i loro nomi per essere un buon programmatore; se sei un buon programmatore, tuttavia, è probabile che tu stia già utilizzando molti modelli senza saperlo.

Sì, i modelli sono essenziali. Ti rimanderò a Che cosa succede se Non userò Modelli di design del software? di Eric Lippert in cui sottolinea:

Variables are a design pattern.

Methods are a design pattern.

Operators -- addition, subtraction, etc -- are a design pattern.

Statements are a design pattern.

Values are a design pattern.

References are a design pattern.

Expressions are a design pattern.

Classes are a design pattern.

Everything you do in programming at all times is a design pattern. Most of the time the pattern is so ingrained into your thinking that you've stopped thinking of it as "a design pattern". The things that you have to learn like "the singleton pattern" and so on are simply patterns that haven't (yet) been baked into whatever language you're using.

Questo significa che hai usato modelli di design senza nemmeno conoscerne il nome. Hai anche usato quelli che sapevi che avevano nomi ma non rendevano conto che erano modelli.

La chiave è in che modo la gente pensa ai modelli ... e in una certa misura incolpo l'educazione (o forse la mancanza di) nei momenti in cui si aspettano che i modelli di progettazione siano come Lego - "noi" Prenderò una fabbrica astratta, una palafitta, un singleton e una facciata ... e si adatteranno tutti insieme. " Spesso si può vedere questo nelle domande poste "quale schema ho bisogno per il problema XYZ" prima che abbiano davvero iniziato a programmare o pensare al progetto nel suo insieme.

Osservando il libro originale Un linguaggio pattern ( wikipedia ) sulla costruzione dell'architettura, un Pattern è qualcosa che usi per risolvere un particolare design. Vuoi mettere una finestra in un muro di borchie? Bene, quindi inserisci alcuni storpi e un'intestazione e una piastra di fondo e così via ( wikipedia ). Questo è uno schema e lo fai perché vuoi mettere una finestra in un muro.

Si noti che nell'esempio precedente, il problema è venuto prima, quindi il modello di progettazione. Ho bisogno di questo, questo è come lo aggiusterò. Viceversa "Metterò alcuni storpi, fondo e così via qui in modo che io abbia una finestra perché avrò bisogno di una finestra" è il modo sbagliato di seguire il modello di una finestra. Allo stesso modo, è il modo sbagliato di utilizzare i pattern nello sviluppo del software.

L'altra cosa da capire è che se hai due persone che lavorano su una parete di un muro, possono comunicare rapidamente e capire cosa sta succedendo quando mettono in una finestra. Entrambi conoscono e comprendono il problema e il modello e come applicarlo. Lo stesso è vero anche con il software. Abbiamo un problema che abbiamo bisogno di troppi oggetti interi creati? Inseriremo un mosca . E così, due programmatori hanno comunicato e sanno come risolvere il problema perché sono in grado di parlare di Pattern.

No. I pattern si applicano meglio per scrivere codice che altri (e te stesso in fondo alla pagina) possono capire.

Applicare un motivo per nulla lo renderà un concetto di design di fantasia, ma quando un modello si adatta a un problema è meglio utilizzarlo piuttosto che trovare una soluzione creativa.

I pattern sono generalmente cliché, funzionano e probabilmente ne hai usati parecchi senza rendertene conto, ma questa non è una scusa per ignorare di conoscerli poiché ne troverai alcuni che non conosci e amplierà il tuo possedere la conoscenza della programmazione piuttosto che capire tutto da soli. Come programmatore autodidatta, questo è un elemento vitale di sviluppo per venire a patti con