Quando ero un programmatore alle prime armi, adoravo i modelli di design. Non ho usato solo schemi di progettazione. Li ho inflitti. Ovunque e ogni volta che potrei. Ero impietoso Aha! Schema di osservatore! Prendi quello! Usa un ascoltatore! Proxy! AbstractFactory! Perché usare uno strato di astrazione quando cinque lo faranno? Ho parlato con molti programmatori esperti e ho scoperto che quasi tutti quelli che leggono il GoF Book attraversano questa fase.

I programmatori inesperti non usano schemi di progettazione. Abusano di schemi di progettazione.

Più recentemente, trovo che tenere a mente principi come il Principio di Responsabilità Unica, e scrivere i test per primi, aiuti i modelli a emergere in un modo più pragmatico. Quando riconosco i modelli, posso continuare a progredirli più facilmente. Li riconosco, ma non cerco più di forzarli sul codice. Se emerge un pattern di Visitor probabilmente è perché ho rifattorizzato la duplicazione, non perché ho pensato in anticipo alle somiglianze tra il rendering di un albero e l'aggiunta dei suoi valori.

I programmatori esperti non usano schemi di progettazione. I modelli di progettazione li usano.

Sia che li si riconosca o no, la maggior parte dei programmatori fa utilizza pattern.

Nel lavoro quotidiano, tuttavia, non si inizia a programmare con uno schema in mente: si riconosce che un modello è emerso nel codice e poi lo nomina.

Alcuni dei modelli comuni sono incorporati in alcune lingue, ad esempio il pattern iteratore incorporato in C # con il foreach parola chiave.

A volte conosci già lo schema che utilizzerai come soluzione comune al problema in questione (ad esempio il schema del repository - sai già che vuoi rappresentare i tuoi dati come una raccolta in memoria).

Come implicito dalla risposta pdr collegata: i pattern di design sono nomi dati a cose che le persone facevano comunque , intese a rendere più facile per le persone discutere di queste cose.

In generale vale la pena apprenderli all'inizio, perché ti danno un'idea delle soluzioni che le persone hanno scoperto che funzionano, in modo da poter contare su anni di esperienza e trial & di errore.

La discussione sui problemi motivanti inclusi con i pattern può darti un'idea dei buoni modi per attaccare il tuo problema, ma a meno che la tua conoscenza del pattern non ti riconosca che esiste una soluzione già nota, devi comunque concentrarti su per prima cosa risolvendo il problema .

Se risulta che usi uno o più pattern esistenti quindi fantastici, hai nomi già pronti che renderanno più facile per gli altri capire il tuo codice.

In generale, no. Ci sono volte in cui i pattern emergono dal mio codice, ma in generale, non li cerco e certamente non dico "Oh, il Bridge Pattern risolverebbe il mio problema!".

Ecco la cosa. La maggior parte dei modelli viene abusata e usata impropriamente senza che le persone considerino mai se sono un buon design. I modelli non sono atomi. Il codice non comprende la permutazione X dei modelli. Per non parlare del fatto che non tutti i pattern sono in realtà buone idee, o che alcune lingue hanno soluzioni a livello di linguaggio che sono di gran lunga superiori ad alcuni pattern.

Sì, la maggior parte dei programmatori che abbia mai incontrato utilizza il modello più comune che esiste, il Big Ball of Mud . Di solito iniziano con architetture ben progettate, ma di solito finiscono qui, soprattutto se iniziano a pensare "dobbiamo usare schemi di progettazione" ovunque e refactare senza pietà.

do you use them?

Sì, sicuramente i programmatori esperti lo fanno. È possibile evitare di utilizzare la maggior parte dei modelli di progettazione (ad eccezione delle semplici cose singleton) per ora; ma più programmi e più complessi sistemi costruisci, più sentirai la necessità di utilizzare modelli di progettazione. Se continui ad evitarlo, inizierai a sentire il dolore quando devi espandere il tuo sistema e modificarlo secondo i nuovi requisiti.

If somewhere in the web I find a way to solve my problem, is this a design pattern?

Non necessariamente. Un modello di progettazione si riferisce a un modo specifico di progettare classi, i loro comportamenti e interazioni per raggiungere un obiettivo specifico (o evitare un problema specifico). Ciò che potresti aver incontrato potrebbe non essere un problema di progettazione, ma una sequenza specifica di passaggi per programmare una determinata API. Ad esempio: c'è una certa sequenza per stabilire una connessione socket. Fallo male e il tuo socket non comunicherà. Quella sequenza di passaggi non costituisce uno schema.

do you (programmers) find yourself looking for patterns

Sì. Gli schemi di progettazione incarnano l'assioma "prevenire è meglio che curare". Se riesci a individuare in anticipo un particolare problema di progettazione imminente, puoi evitare modifiche ingenti per adattarle in seguito. Quindi paga sapere in anticipo i modelli di progettazione e cercare i luoghi in cui devi utilizzarli mentre sviluppi la tua applicazione.

where am I supposed to look btw?

Dato che sei uno studente probabilmente non hai visto i tipici problemi che ispirano i modelli di progettazione. Consiglio vivamente di dare un'occhiata a Head First Design Patterns . Prima presentano un problema di progettazione e poi mostrano come un particolare modello può risolverlo / evitarlo.

I modelli di progettazione non sono stati insegnati quando ero a scuola. E, per la maggior parte della mia carriera di programmatore, ho lavorato con legacy, codice non orientato agli oggetti. Negli ultimi anni, ho cercato di impararli perché suonano come una buona idea. Tuttavia, devo confessare che ogni volta che ho mai preso un libro o provato a leggere un tutorial sull'argomento, i miei occhi si sono vetrificati e non ho davvero imparato nulla di pratico su di loro.

Non posso credere di averlo ammesso in pubblico. Penso che probabilmente ho perso qualche credito geek che avrei potuto stabilire nel corso degli anni.

Non cercare tendenze

Qualsiasi soluzione di programmazione standard per un determinato problema può essere considerata un modello di progettazione, non importa quanto siano popolari o se altri programmatori li usano o meno.

Potresti già utilizzare uno schema di progettazione che non è ancora stato inventato / specificato.

Non provare a utilizzarli, prova a pensare nei loro termini

Il problema con i modelli di progettazione è che a volte i programmatori vogliono inserirvi i loro problemi quando è il contrario.

Ricorda che le convenzioni progettuali dei modelli di progettazione hanno un tipico problema da risolvere, puoi anche combinare schemi di progettazione per affrontare altri problemi più grandi. Questo è tipico delle architetture orientate ai servizi, basta vedere alcuni dei modelli SOA che ci sono .

Cercali allo stato selvatico

Ci sono molti progetti open source in cui troverai modelli di design applicati. Un esempio che viene in mente è Joomla: troverai singletons , osservatori . Le librerie della GUI avranno il schema di decorazione , schema di comando implementato, e forse anche peso vivo .

Esistono altri modelli come i pattern di dati, ad esempio il solo Progetto Doctrine, il modello di record attivo ( 1.x), modello gestore entità (2.x), unità di lavoro , repository , oggetto query , mappatura metadata , mappatura dei dati , e altri più generali come pattern di strategia e modello decoratore .

Ci sono così tante soluzioni interessanti da scegliere. Vedi Patterns of Enterprise Architecture di Martin Fowler , ci sono anche modelli del modello di dati .

Impara semplicemente quando arriva il momento

Impara loro, conoscili, ossessionati da loro e quando verrà il momento saprai come risolvere il problema di programmazione x, sarai già un programmatore migliore a quel punto.

Diventa un architetto

Direi che essere in grado di pensare in termini di pattern per risolvere problemi, efficacemente ti trasforma in un architetto software . Anche se non vuoi essere un architetto software di per sé, le tue soluzioni avranno più qualità tecnica, maggiore pulizia e migliore scalabilità, in termini di progettazione, per impostazione predefinita.

Ho programmato circa 7 anni in C ++ e ho imparato modelli circa 2 anni fa. La maggior parte dei modelli ha probabilmente alcune applicazioni, ma nel mio utilizzo, alcuni sono migliori di altri. Devi pensare perché li stai usando.

Il pattern iteratore ha effettivamente reso il mio codice più confuso e ha aggiunto una complessità non necessaria. Posso ottenere la stessa manutenibilità usando typedef per i tipi di vettore STL. E ogni modifica che faccio alla classe che viene ripetuta devo anche fare la lezione di iteratore.

Il metodo factory, tuttavia, è stato estremamente utile, in base al polimorfismo che fornisce. Ho dimenticato chi l'ha detto, ma l'affermazione "riusabilità significa che il vecchio codice può usare il nuovo codice", è assolutamente vero con il modello di fabbrica.

Ho usato il modello di metodo del modello per anni senza nemmeno sapere che era un "modello di progettazione".

Il pattern Observer è stato utile in alcuni casi, a volte no. A volte si deve prevedere la complessità per determinare se la complessità complessiva del pattern Observer è valsa la pena. Abbiamo un programma che utilizza circa 10 abbonati e potrebbero essercene molti altri, quindi il modello di osservatore / sottoscrittore è stato utile. Un altro programma, tuttavia, ha due display GUI. Ho implementato il pattern di osservatore per questo programma, ed è stato in gran parte inutile, semplicemente perché ha aggiunto complessità e non mi aspetto di aggiungere più display.

Penso che quelli che dicono di usare sempre i pattern presumono che il tuo programma sarà infinitamente complesso, ma come in tutto, c'è un punto di pareggio in termini di complessità.

Aggiunta a Lunivore. Mi piace citare questo dal primo libro della testa

        ## **Three steps to great software** ##     

• Assicurati che il software faccia ciò che il cliente desidera
• Applica principi orientati agli oggetti validi
• Cerca un design mantenibile e riutilizzabile

È durante la terza fase, dopo che il sistema sta funzionando nel modo in cui è previsto. È il momento di applicare gli schemi per rendere il software pronto per gli anni a venire.

Are they really used by the majority of programmers?

Direi di sì. In ADO.Net esiste una classe DataAdapter per dare un semplice esempio, ma a seconda di quale area si desidera specializzare, i pattern possono variare.

Speaking of experience, I've had some troubles while programming, things I could not solve for a while, but google and some hours of research solved my problem. If somewhere in the web I find a way to solve my problem, is this a design pattern? Am I using it?

No, non è un modello di design nella mia mente. Un modello di progettazione tende ad avere una disposizione di classi e metodi che definiscono la ricetta di un modello.

Preferirei pensare a quello che hai fatto lì come pratica comune. Attenzione però alla codifica di copia e incolla.

And also, do you (programmers) find yourself looking for patterns (where am I supposed to look btw?) when you start the development? If so, this is certainly a habit that I must start to embrace.

A volte, mentre vedo lo stesso codice più e più volte, potrei trovare un modo per rifattorizzare il codice in un pattern o se ricordo una soluzione a un problema simile che coinvolge un pattern lo estrometterò e lo useremo. Head First Design Patterns contiene più di alcuni pattern mentre Ricostruzione sarebbe un suggerimento per le pratiche di codifica che potrebbero portare a trovare vari modelli. Se desideri un altro possibile punto di partenza, consulta Modelli e prassi Microsoft .

I modelli di apprendimento non stanno solo imparando qualcosa. Impari cosa puoi fare con i linguaggi di programmazione. Io stesso ho imparato molto sulla programmazione orientata agli oggetti semplicemente imparando come funziona un pattern (il schema di presentazione in questo caso).

Come menzionato da Oded, la maggior parte dei programmatori li usa a volte senza nemmeno riconoscerlo. La bellezza dei pattern è che puoi risolvere problemi specifici con un pattern predefinito in modo da non dover pensare molto alle cose architettoniche.

Imparerai i modelli mentre inizi a lavorare con progetti esistenti. Ci sono così tanti modelli là fuori che puoi imparare, e non è il momento di padroneggiarli tutti perché dipende da quale progetto stai lavorando. Ogni volta che ne incontri uno, informalo per vedere come viene utilizzato.