Come studiare i modelli di progettazione? [chiuso]

Ho letto circa 4-5 libri sugli schemi di progettazione, ma ancora non mi sento di avvicinarmi al livello intermedio degli schemi di progettazione?

Come dovrei andare a studiare modelli di design?

Esiste un buon libro per i modelli di design?

So che questo arriverà solo con l'esperienza, ma ci deve essere un modo per dominarli?

Il modo migliore è iniziare a programmare con loro. I modelli di design sono un grande concetto che è difficile da applicare semplicemente leggendoli. Prendi alcune implementazioni di esempio che trovi online e costruisci attorno ad esse.

Una grande risorsa è la pagina Data & Object Factory . Esaminano gli schemi e offrono esempi concettuali e reali. Anche il loro materiale di riferimento è eccezionale.

Ho letto tre libri e non ho ancora capito molto bene i modelli fino a quando non ho letto Head First Design Patterns di OReilly. Questo libro mi ha aperto gli occhi e mi ha davvero spiegato bene.

I miei due centesimi per una domanda così vecchia

Alcune persone hanno già menzionato, pratica e refactoring. Credo che l'ordine giusto per conoscere gli schemi sia questo:

1. Scopri Test Driven Development (TDD)
2. Impara il refactoring
3. Impara i modelli

Molte persone ignorano 1, molti credono di poter fare 2, e quasi tutti vanno dritto per 3.

Per me la chiave per migliorare le mie competenze software era l'apprendimento del TDD. Potrebbe essere un lungo periodo di codifica dolorosa e lenta, ma scrivere i test prima ti farà sicuramente pensare molto al tuo codice. Se una classe ha bisogno di troppi piatti o si rompe facilmente, inizi a notare cattivi odori abbastanza velocemente

Il principale vantaggio di TDD è che perdi la paura di refactoring del tuo codice e ti costringe a scrivere classi altamente indipendenti e coerenti. Senza una buona serie di test, è troppo doloroso toccare qualcosa che non è rotto. Con la rete di sicurezza ti avventurerai davvero in drastiche modifiche al tuo codice. Questo è il momento in cui puoi davvero iniziare ad imparare dalla pratica.

Ora arriva il punto in cui devi leggere libri sugli schemi e, a mio avviso, è una completa perdita di tempo provarci troppo. Ho capito davvero bene i modelli solo dopo aver notato che ho fatto qualcosa di simile, oppure ho potuto applicarlo al codice esistente. Senza i test di sicurezza o le abitudini di refactoring, avrei aspettato un nuovo progetto. Il problema dell'uso dei pattern in un nuovo progetto è che non si vede come incidono o cambiano un codice funzionante. Ho capito un modello software solo dopo aver refactored il mio codice in uno di essi, mai quando ne ho introdotto uno nuovo nel mio codice.

Derek Banas ha realizzato tutorial su YouTube per progettare modelli che mi piacciono molto:

http://www.youtube.com/playlist?list=PLF206E906175C7E07

Possono essere un po 'a corto di tempo, ma i suoi tempi e la presentazione li rendono molto divertenti da imparare.

Pratica, pratica, pratica.

Puoi leggere di suonare il violoncello per anni e non essere ancora in grado di fare un inchino allo strumento e fare qualsiasi cosa che suoni come la musica.

I modelli di progettazione sono meglio riconosciuti come un problema di alto livello; uno che è rilevante solo se si ha l'esperienza necessaria per riconoscerli utili. È positivo che tu riconosca che sono utili, ma a meno che tu non abbia visto situazioni in cui si applicherebbero o che abbiano applicato, è quasi impossibile capire il loro vero valore.

Il punto in cui diventano utili è quando riconosci i modelli di progettazione nel codice altrui o riconosci un problema nella fase di progettazione che si adatta bene a un modello; e quindi esaminare il modello formale, esaminare il problema e determinare quale sia il delta tra di loro e ciò che dice sia sul modello che sul problema.

È davvero lo stesso della codifica; K&R può essere la "bibbia" di C, ma leggerlo più volte non è un'esperienza pratica; non c'è sostituto per esperienza.

Pratica pratica pratica. Penso che da 4 a 5 libri sia persino un esercizio di lettura eccessiva senza una buona dose di pratica. Il modo migliore per farlo, credo, è iniziare a refactoring dei tuoi progetti attuali usando gli schemi. Oppure, se non hai progetti a cui stai lavorando attivamente, fallo a modo tuo e poi prova a rifattorizzare i pattern .

Non puoi apprezzarli completamente se non hai sofferto dei problemi che risolvono. E tieni presente che non sono proiettili d'argento: non è necessario memorizzarli e spingerli duramente per applicarli al volo. I miei due centesimi..

Ponetevi queste domande:

Cosa fanno?

Cosa disaccoppiano / coppia?

Quando dovresti usarli?

Quando non dovresti usarli?

Quale caratteristica della lingua mancante li farebbe scomparire?

Quale debito tecnico incorri nell'usarlo?

C'è un modo più semplice per portare a termine il lavoro?

Ho scoperto che è un po 'difficile comprendere o comprendere i benefici di alcuni schemi fino a quando uno capisce i problemi che risolvono e l'altro (peggio) i modi in cui i problemi sono stati implementati.

A parte i libri su GOF e POSA, non ne ho letto nessuno, quindi non posso darti altri consigli. In realtà devi solo avere una comprensione dei domini dei problemi e penso che molti sviluppatori meno esperti potrebbero non essere in grado di apprezzare i vantaggi dei modelli. Questo non è leggero contro di loro. È molto più facile abbracciare, comprendere e apprezzare le buone soluzioni quando si deve prima lottare con alternative scarse.

In bocca al lupo

Sono stati dati molti buoni esempi. Vorrei aggiungerne uno:

Applicarli erroneamente. Non è necessario farlo intenzionalmente, accadrà quando proverai ad applicarli nel Design-Pattern-fit iniziale. Durante quel periodo, ogni singolo problema che vedrai sembrerà adattarsi esattamente a un modello di progettazione. Spesso i problemi sembrano adattarsi allo stesso modello di progettazione per qualche motivo (Singelton è un candidato primario per quello).

E applicherai il modello e sarà buono. E alcuni mesi dopo dovrai cambiare qualcosa nel codice e vedere che usare quel particolare schema non è stato così intelligente, perché ti sei codificato in un angolo e devi rifattorizzare di nuovo.

Certo, non è proprio una risposta fai-e-imparerai-in-21-giorni, ma nella mia esperienza è molto probabile che ti dia una buona visione della questione.

Hai letto "Design Patterns Explained", di Allan Shalloway.

Questo libro è molto diverso dagli altri libri di modelli di design perché non è tanto un catalogo di modelli, ma presenta principalmente un modo di decomporre uno spazio problematico che si associa facilmente ai modelli.

I problemi possono essere scomposti in due parti: cose comuni e cose che variano. Una volta fatto ciò, mappiamo le cose comuni a un'interfaccia e le cose che variano a un'implementazione. In sostanza, molti schemi ricadono in questo "schema".

Ad esempio, nel modello di strategia, le cose comuni sono espresse come contesto della strategia e le parti variabili sono espresse come strategie concrete.

Ho trovato questo libro altamente pensato provocando in contrasto con altri libri modello che, per me, hanno lo stesso grado di eccitazione che leggere un elenco telefonico.

Hai provato il libro Gang of Four?

Modelli di progettazione: elementi di software riutilizzabile orientato agli oggetti

Per i libri, consiglierei Design Patterns Explained e Head First Design pattern . Per imparare davvero questi schemi, dovresti guardare il tuo codice esistente. Cerca quali schemi stai già utilizzando. Guarda gli odori di codice e quali schemi potrebbero risolverli.

Ho guidato alcuni gruppi di discussione sui modelli di progettazione (il nostro sito ) e ho letto 5 o 6 libri di modelli. Consiglio di iniziare con il libro Head First Design Patterns e di partecipare o iniziare un gruppo di discussione. Il primo libro potrebbe sembrare un po 'Hasboro all'inizio, ma alla maggior parte delle persone piace leggere un capitolo o due.

Usa la risorsa eccezionale: la Guida all'apprendimento di modelli di Joshua Kereivisky per l'ordinamento dei modelli e per aiutare il tuo gruppo di discussione. Per esperienza l'unica modifica che suggerisco all'ordinamento è quella di mettere al primo posto la strategia. La maggior parte degli sviluppatori di oggi ha sperimentato una buona o cattiva incarnazione di una Fabbrica, quindi iniziare con Fabbrica può portare a molte conversazioni e confusione sul modello. Questo tende a focalizzarsi su come studiare e apprendere modelli che sono piuttosto essenziali in quel primo incontro.

Raccomando HeadFirst DesignPattern. Leggere il libro non è abbastanza, dopo aver assimilato i concetti necessari per trovare le risposte a molte domande sorgono nella tua mente e provare a scoprire le applicazioni della vita reale in cui è possibile utilizzare questi schemi. Sto facendo lo stesso e ho iniziato a fare domande anche se quelle domande sembrano sciocche.

Il mio suggerimento sarebbe una combinazione di implementarne alcuni e analizzarne alcune. Ad esempio, all'interno di .Net, ci sono usi dei modelli di adattatore se si guardano gli adattatori di dati, così come alcuni altri se si fa un po 'di scavare nel framework.

Non conosco il miglior libro, ma i puristi potrebbero dire Design Patterns: Elements of Reusable Object-Oriented Software

Per quanto riguarda il mio preferito, mi piacciono i Head First Design Patterns pubblicati da O'Reilly. È scritto con una voce colloquiale che mi piace. Quando l'ho letto, ho rivisto il mio codice sorgente allo stesso tempo per vedere se si applicava a ciò che stavo leggendo. In tal caso, ho effettuato il refactoring. È così che ho imparato la catena di responsabilità.

Pratica - Pratica - Pratica.

I modelli di progettazione sono solo strumenti - un po 'come le funzioni della libreria. Se sai che sono lì e la loro funzione approssimativa, puoi andare a scavarli da un libro quando necessario.

Non c'è nulla di magico nei modelli di design e ogni buon programmatore ne ha capito il 90% prima che uscisse un libro. Per la maggior parte considero i libri più utili nel definire semplicemente i nomi per i vari schemi in modo da poterli discutere più facilmente.

Il modo in cui ho imparato i modelli di progettazione è scrivendo un sacco di software davvero terribile. Quando avevo circa 12 anni, non ho idea di cosa sia buono o cattivo. Ho appena scritto pile di codice spaghetti. Nei successivi 10 anni circa ho imparato dai miei errori. Ho scoperto cosa ha funzionato e cosa no. Ho inventato in modo indipendente la maggior parte dei modelli di progettazione comuni, quindi quando ho sentito per la prima volta quali fossero i modelli di progettazione, ero molto entusiasta di conoscerli, quindi sono rimasto molto deluso dal fatto che fosse solo una raccolta di nomi per cose che già conoscevo intuitivamente. (quella battuta sull'insegnamento del C ++ in 10 anni non è in realtà uno scherzo)

Morale della storia: scrivere un sacco di codice. Come altri hanno già detto, pratica, pratica, pratica. Penso che fino a quando non capirai perché il tuo design attuale è cattivo e cerchi un modo migliore, non avrai una buona idea di dove applicare i vari modelli di design. I libri di schemi di progettazione dovrebbero fornirti una soluzione raffinata e una terminologia comune per discuterne con altri sviluppatori, non una soluzione incollabile per un problema che non capisci.

L'idea che legge modelli di progettazione, pratica la loro codifica non aiuterà davvero l'IMO. Quando leggi questi libri 1. Cerca il problema di base che risolve un particolare modello di progettazione, a partire da Creational Patterns è la soluzione migliore. 2. Sono sicuro che hai scritto codice in passato, analizza se hai affrontato gli stessi problemi che i modelli di progettazione mirano a fornire una soluzione. 3. Prova a riprogettare / rielaborare il codice del fattore o forse ricominciare da capo.

Informazioni sulle risorse è possibile controllare queste

1. www.dofactory.com
2. Modelli di progettazione: elementi di software riutilizzabile orientato agli oggetti (serie di elaborazione professionale Addison-Wesley) di Erich Gamma, Richard Helm, Ralph Johnson e John M. Vlissides
3. Patterns of Enterprise Application Architecture di Martin Fowler

1 è un avvio rapido, 2 sarà uno studio approfondito..3 spiegherà o dovrebbe farti pensare che cosa hai imparato in 2 si adatta al software aziendale.

I miei 2 centesimi ...

Penso che sia anche difficile studiare modelli di progettazione. Devi sapere di più su OOP e alcune esperienze con lo sviluppo di applicazioni medio-grandi. Per me, studio come gruppo di sviluppatori per discutere. Seguiamo una guida di apprendimento per progettare modelli che hanno completato lo studio dei modelli. Ci sono sviluppatori C # e JavaScript che si uniscono. È interessante per me che lo sviluppatore C # scriva i codici in JavaScript e lo sviluppatore JavaScript faccia la stessa cosa per i codici C #. Dopo aver lasciato un incontro, faccio anche ricerche e leggo alcuni libri a casa per esaminarli. Il modo migliore per capire di più e ricordare nella mia mente è fare blog con esempi sia in C # sia in JavaScript qui http://tech.wowkhmer.com/category/Design-Patterns.aspx .

Vorrei suggerire prima di andare a ogni modello di design, per favore capisci il nome dei modelli. Inoltre, se qualcuno conosce il concetto, ti preghiamo di spiegare e dare un esempio non solo di programmazione ma nel mondo letto.

per esempio:

Metodo di fabbrica:

Leggi il mondo: do solo soldi $ 5, $ 10 o $ 20 e produrrà la pizza senza sapere nulla su come produce, ho solo una pizza piccola, media o grande che dipende dall'ingresso di denaro in modo da poter mangiare o fare qualsiasi cosa.

Programmazione: il client passa semplicemente il valore del parametro $ 5, $ 10 o $ 20 al metodo di fabbrica e restituirà l'oggetto Pizza. Quindi il client può usare quell'oggetto senza sapere come viene elaborato.

Non sono sicuro che questo possa aiutarti. Dipende dal livello di conoscenza delle persone che partecipano alla riunione.

Penso che sia necessario esaminare alcuni dei problemi che hai riscontrato come sviluppatore in cui ti sei strappato i capelli dopo aver dovuto rivedere il codice per la decima volta a causa di un altro cambiamento di progettazione. Probabilmente hai un elenco di progetti in cui hai sentito che c'erano molte rielaborazioni e dolore.

Da tale elenco è possibile derivare gli scenari che i Pattern di progettazione intendono risolvere. C'è stato un tempo in cui era necessario eseguire la stessa serie di azioni su diversi set di dati? Dovrai essere in grado di sviluppare in futuro le funzionalità di un'applicazione ma vuoi evitare di rielaborare tutta la logica per le classi esistenti? Inizia con quegli scenari e torna al catalogo dei modelli e ai loro rispettivi problemi che dovrebbero risolvere. Probabilmente vedrai alcune corrispondenze tra il GoF e la tua biblioteca di progetti.

Per un principiante, i modelli di Head First Design farebbero, una volta che avremo familiarità con tutti i modelli, quindi proveremo a visualizzare gli oggetti in tempo reale in quei modelli.

Il libro ti aiuterà a comprendere i concetti di base, a meno che fino a quando non ti sarai implementato nel mondo reale, CANT diventerai un MAESTRO dei MODELLI DI DESIGN