Essendo uno studente IT, di recente uno dei miei insegnanti mi ha dato una panoramica dei modelli di progettazione. Ho capito a cosa servono, ma alcuni aspetti continuano a infastidirmi.

Sono davvero utilizzati dalla maggior parte dei programmatori?

Parlando di esperienza, ho avuto dei problemi durante la programmazione, cose che non sono riuscito a risolvere per un po ', ma Google e alcune ore di ricerca hanno risolto il mio problema. Se da qualche parte nel web trovo un modo per risolvere il mio problema, è questo un modello di progettazione? Lo sto usando?

Inoltre, (programmatori) ti ritrovi a cercare modelli (dove dovrei guardare, a proposito?) Quando inizi lo sviluppo? Se è così, questa è certamente un'abitudine che devo iniziare ad abbracciare.

AGGIORNAMENTO: Penso che quando chiedo se i programmatori li usano, chiedo se quando hai un problema per risolverlo pensi "Oh, dovrei usare quel modello".

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

I programmatori principianti non usano schemi di progettazione. Abusano dei modelli di progettazione.

Più recentemente, trovo che tenere a mente principi come il principio della responsabilità singola e scrivere prima i test, aiuta gli schemi a emergere in modo più pragmatico. Quando riconosco gli schemi, posso continuare a farli progredire più facilmente. Li riconosco, ma non provo più a forzarli sul codice. Se emerge un modello di visitatore è probabilmente perché ho modificato la duplicazione, non perché ho pensato in anticipo alle somiglianze del rendering di un albero rispetto all'aggiunta dei suoi valori.

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

Se uno li riconosce o no, la maggior parte dei programmatori fanno modelli di consumo.

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

Alcuni dei pattern comuni sono integrati in alcune lingue, ad esempio il pattern iteratore è integrato in C # con la foreachparola chiave.

A volte conosci già il modello che utilizzerai come soluzione comune al problema attuale (ad esempio il modello di repository : sai già che vuoi rappresentare i tuoi dati come una raccolta in memoria).

Come suggerito dalla risposta collegata a pdr : i modelli di progettazione sono nomi dati a cose che le persone facevano comunque , intese a rendere più facile per le persone discutere di quelle cose.

In generale vale la pena impararli all'inizio, perché ti danno un'idea delle soluzioni che le persone hanno trovato in grado di lavorare, in modo da poter contare su anni di esperienza, prove ed errori.

La discussione sui problemi motivanti inclusi con i modelli può darti in primo luogo un'idea dei modi migliori per attaccare il tuo problema, ma a meno che la tua conoscenza dei modelli non ti consenta di riconoscere che esiste una soluzione già nota, devi comunque concentrarti solo sulla risoluzione del prima il problema .

Se si scopre di usare uno o più pattern esistenti allora grandi, hai nomi già pronti che renderanno più facile agli altri la comprensione del tuo codice.

In generale, no. Ci sono momenti 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 utilizzata in modo improprio senza che le persone possano mai considerare se sono di buon design. I modelli non sono atomi. Il codice non comprende la permutazione X dei modelli. Per non parlare del fatto che non tutti gli schemi sono in realtà buone idee o che alcune lingue hanno soluzioni a livello linguistico che sono di gran lunga superiori ad alcuni schemi.

sì, la maggior parte dei programmatori che abbia mai incontrato usano il modello più comune che ci sia, la Big Ball of Mud . Di solito iniziano con architetture ben progettate, ma di solito finiscono qui, soprattutto se iniziano a pensare "dobbiamo usare i modelli di progettazione" in tutto il luogo e refactoring senza pietà.

li usi?

Sì, sicuramente programmatori esperti lo fanno. Per ora puoi evitare di usare la maggior parte dei modelli di progettazione (esclusi i semplici elementi singleton); ma più programmi e più sistemi complessi crei, più sentirai la necessità di utilizzare modelli di progettazione. Se lo eviti ancora, inizierai a sentire il dolore quando devi espandere il tuo sistema e cambiarlo secondo i nuovi requisiti.

Se da qualche parte nel web trovo un modo per risolvere il mio problema, è questo un modello di progettazione?

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

(programmatori) vi trovate alla ricerca di schemi

Sì. I modelli progettuali incarnano l'assioma "prevenire è meglio che curare". Se è possibile individuare in anticipo un particolare problema di progettazione imminente, è possibile impedire riprogettazioni di massa per adattarsi alle modifiche in un secondo momento. Quindi vale la pena conoscere in anticipo i modelli di progettazione e cercare i luoghi in cui è necessario utilizzarli durante la creazione dell'applicazione.

dove dovrei guardare tra?

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

I pattern di design non sono stati insegnati quando ero a scuola. E, per gran parte della mia carriera di programmatore, ho lavorato con codice legacy, non orientato agli oggetti. Negli ultimi anni, ho cercato di impararli perché sembrano un'ottima idea. Tuttavia, devo confessare che ogni volta che ho mai preso un libro o ho cercato di leggere un tutorial sull'argomento, i miei occhi si sono guardati e non ho davvero imparato nulla di pratico su di loro.

Non posso credere di averlo ammesso in pubblico. Penso di aver probabilmente perso qualsiasi credito geek che avrei potuto ottenere nel corso degli anni.

Non cercare la tendenza

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 un modello di progettazione che non è stato ancora inventato / specificato.

Non provare a usarli, prova a pensare nei loro termini

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

Ricorda che la convenzione di progettazione dei modelli di progettazione presenta un problema tipico da risolvere, puoi persino combinare i modelli di progettazione per affrontare altri problemi più grandi. Questo è un po 'tipico nelle architetture orientate ai servizi, basta vedere alcuni dei modelli SOA che ci sono .

Cercali allo stato brado

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

Esistono altri modelli come i modelli di dati, ad esempio solo il Progetto Doctrine ha utilizzato, il modello di record attivo (1.x), il modello di gestione entità (2.x), l' unità di lavoro , il repository , l'oggetto query , la mappatura dei metadati , i dati mappatura e altri più generali come il modello di strategia e il modello di decorazione .

Ci sono così tante soluzioni interessanti tra cui scegliere. Vedi Patterns of Enterprise Architecture di Martin Fowler , ci sono anche pattern di modelli di dati .

Imparali solo quando arriva il momento

Imparali, conoscili, ossessionali e quando arriverà saprai come risolvere il problema di programmazione x, a quel punto sarai già un programmatore migliore.

Diventa un architetto

Direi che essere in grado di pensare in termini di modello per risolvere i problemi, ti trasforma effettivamente in un architetto del software . Anche se non vuoi essere un architetto del software in sé, le tue soluzioni avranno più qualità tecnica, saranno più pulite e miglioreranno la scalabilità, in termini di design, per impostazione predefinita.

Ho programmato per circa 7 anni in C ++ e ho imparato schemi 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 modello iteratore ha reso il mio codice più confuso e ha aggiunto complessità inutili. Posso ottenere la stessa manutenibilità usando typedefs per i tipi vettoriali STL. E qualsiasi modifica apportata alla classe in iterazione, devo anche apportare alla classe iteratrice.

Il metodo di fabbrica, tuttavia, è stato estremamente utile, basato sul polimorfismo che fornisce. Dimentico chi l'ha detto, ma l'affermazione "riusabilità significa che il vecchio codice può usare il nuovo codice", è sicuramente vera con il modello di fabbrica.

Ho usato il modello di modello per anni senza nemmeno sapere che fosse un "modello di progettazione".

Il modello Observer è stato utile in alcuni casi, a volte no. A volte è necessario prevedere la complessità per determinare se la complessità ambientale del modello Observer ne valga la pena. Abbiamo un programma che utilizza circa 10 abbonati e potrebbero essercene molti di più, quindi il modello osservatore / abbonato è stato utile. Un altro programma, tuttavia, ha due display della GUI. Ho implementato il modello di osservatore per questo programma, ed è stato in gran parte superfluo, semplicemente perché ha aggiunto complessità e non prevedo di aggiungere più schermi.

Penso che coloro che affermano di usare sempre i modelli presumano che il tuo programma sarà infinitamente complesso, ma come in ogni cosa, esiste un punto di pareggio in termini di complessità.

Aggiunta a Lunivore. Mi piacerebbe citare questo dal primo libro di testa

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

• Assicurati che il software faccia quello che vuole il cliente
• Applicare buoni principi orientati agli oggetti
• Cerca un design sostenibile e riutilizzabile

È durante la terza fase, dopo che il sistema funziona nel modo previsto. È tempo di applicare gli schemi per rendere il software pronto per gli anni a venire.

Sono davvero utilizzati dalla maggior parte dei programmatori?

Immagino di si. In ADO.Net esiste una classe DataAdapter per fornire un semplice esempio, sebbene a seconda dell'area che si desidera specializzare, i modelli possono variare.

A proposito di esperienza, ho avuto dei problemi durante la programmazione, cose che non sono riuscito a risolvere per un po ', ma Google e alcune ore di ricerca hanno risolto il mio problema. Se da qualche parte nel web trovo un modo per risolvere il mio problema, è questo un modello di progettazione? Lo sto usando?

No, questo non è un modello di progettazione per me. 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 una pratica comune. Attenzione però alla copia e incolla della codifica.

Inoltre, (programmatori) ti ritrovi a cercare modelli (dove dovrei guardare tra l'altro?) Quando inizi lo sviluppo? Se è così, questa è certamente un'abitudine che devo iniziare ad abbracciare.

A volte, vedendo lo stesso codice più volte, potrei trovare un modo per refactificare il codice in un modello o se ricordo una soluzione a un problema simile che coinvolge un modello, lo estrarrò e lo userò. Head First Design Patterns ha più di un paio di pattern, mentre Refactoring sarebbe un suggerimento per pratiche di codifica che potrebbero portare a trovare vari pattern. Se vuoi un altro possibile punto di partenza, guarda i modelli e le pratiche di Microsoft .

I modelli di apprendimento non sono solo imparare qualcosa. Impara cosa puoi fare con i linguaggi di programmazione. Da parte mia ho imparato molto sulla programmazione orientata agli oggetti solo imparando come funziona un modello (il modello composito in questo caso).

Come menzionato da Oded, la maggior parte dei programmatori li usa a volte senza nemmeno riconoscerlo. Il bello dei modelli è che puoi risolvere problemi specifici con un modello predefinito, così non devi pensare molto alle cose architettoniche.

Imparerai schemi quando inizi a lavorare con progetti esistenti. Ci sono così tanti schemi là fuori da imparare, e non vale la pena di padroneggiarli tutti perché dipende da quale progetto stai lavorando. Ogni volta che ti imbatti in uno, impara a usarlo per vedere come viene utilizzato.