Il libro GoF è ancora quello da leggere? [duplicare]

Raccomando di leggere prima il libro Head First, in quanto fa un lavoro migliore per spiegare perché sono necessari modelli di design. Successivamente, puoi utilizzare il libro GoF per gli esempi e come riferimento.

Ho paura del giorno in cui gli schemi di quel libro non esisteranno più. È probabile che quel giorno non venga mai. Prendi il libro.

Rimani con il GoF. Inoltre, ti suggerisco di leggere quanto segue:

"Workbook di Java (TM) di Design Patterns" di Steven John Metsker (ISBN 0201743973)

Penso che questo libro sia un bel complemento del GoF o potrebbe essere usato al sicuro invece del GoF se stai imparando o lavorando con Java. Libri simili esistono per altri linguaggi come C # e Ruby, ma non posso attestarne la qualità poiché non li ho letti.

"Refactoring Workbook" di William C. Wake (ISBN 0321109295)

Il refactoring va di pari passo con i pattern. Questa è una bella cartella di lavoro da leggere.

Brown et al "AntiPatterns: software di refactoring, architetture e progetti in crisi" (ISBN 0471197130)

L'altro lato della medaglia sono anti-pattern, odori di codice che urlano per il refactoring. Questo libro è buono (almeno il primo semestre riguarda gli anti-pattern relativi al software).

Craig Larmans "" Applicazione di UML e pattern: introduzione all'analisi orientata agli oggetti e progettazione e sviluppo iterativo (terza edizione) "(ISBN 0131489062)

Il libro di Larman sta diventando praticamente un libro di testo preferito per i corsi di laurea in ingegneria del software e analisi dei sistemi. Fa un buon lavoro nel percorrere l'utilizzo di UML e dei pattern in un processo iterativo.

"Purely Functional Data Structures" di Chris Okasaki (ISBN 0521663504)

Considererei questo libro una volta che avrai sviluppato una buona conoscenza pratica di modelli, anti-pattern e ri-factoring. È un trattato teorico di schemi e strutture dati da un punto di vista puramente funzionale.

Una delle cose con il GoF (e libri che portano quel testimone) è che quei pattern sono il prodotto di un'epoca in cui la programmazione generica veniva finalmente realizzata in C ++. Gli schemi qui presentati esistevano per adattarsi a un paradigma OO e procedurale / algoritmico.

Molti di questi pattern (visitatore ad esempio) non hanno molte ragioni per esistere in linguaggi che trattano le funzioni come oggetti di prima classe. Non toccherò questo libro senza una buona conoscenza dei modelli e dei linguaggi funzionali, sebbene

Ne avrai ancora bisogno. Continuerete a tornare ad esso per il doppio controllo e piccole revisioni e buoni esempi. Tienilo sul tuo scaffale. Se sei un principiante, prendi la testa per prima. Al contrario, sono molto interessato a scoprire un libro con un punteggio superiore a GOF: -)

Sicuramente uno per mantenere una copia di intorno. Ho avuto il libro dei GoF da quando ho iniziato a usare il software e ho scoperto che è uno di quei libri che ottengo di più ogni volta che lo rileggo (e no, non leggo tutto il testo da copertina a copertina - solo il modello dispari qua e là). È, tuttavia, uno di quei libri che ho sentito come un "principiante", non ne ho mai avuto più di quello che ho fatto più avanti nella mia carriera. Ho scoperto che avere più esperienza rende il libro molto più interessante e, ovviamente, più pertinente.

vai per l'Head First. spiega come scrivi il codice nel modo consueto, quale sarebbe il problema con una modifica non eseguita nel modo giusto, il principio di progettazione da applicare, il refactoring e quindi indirizza il risultato a quale schema hai appena utilizzato.

ho trovato i principi di progettazione più utili. non si sarebbe preoccupato dei modelli se i principi non fossero stati spiegati

Dipende molto dal tuo ambito. Se si è più di un tipo di Java / C # o hardcode C ++ aziendale, allora sì, andare a ottenere un GoF e probabilmente anche altri libri sull'argomento (vedere altre risposte). Tuttavia, se riesci a immaginare di lavorare in un linguaggio dinamico con funzioni di ordine superiore e concetti più avanzati, per lo più non avrai bisogno di nessuno di questi modelli. Ancora peggio: diventerai meno produttivo dal momento che cercheresti modelli da implementare invece di pensare in termini linguistici e (ab) usando il suo potere. Guardando Python, Ruby, (moderno) Perl, Erlang, Scala, Clojure, Lisp, lo chiami, in ognuna di queste lingue non sono necessari modelli da GoF, poiché francamente i pattern sono un buon modo per risolvere alcuni problemi inerenti in lingue senza costrutti di ordine superiore.

Detto questo, apprendi comunque i modelli in ogni caso, ma sii critico con loro e impara ad usarli correttamente e con parsimonia. Non sono il proiettile d'argento e non lo saranno mai.

Sicuramente inizia con GoF - ma ricorda che da quando è uscito ci sono numerosi libri con vari cataloghi di pattern (la maggior parte delle serie "signature" mi vengono in mente, come PEAAA o Modelli di integrazione aziendale ) che porta l'idea del modello in aree più specifiche.

Ricorda inoltre che l'implementazione di alcuni pattern è potenzialmente un po 'arcaica a seconda della lingua in cui stai lavorando. Ad esempio, anche se potresti implementare il codice Java praticamente come in C # (e questo avrebbe andava bene quando il C # 1 stava bussando) avresti perso il potenziale che alcune caratteristiche del linguaggio moderno forniscono. Specificamente per .net mi piacciono gli esempi di dotfactory , Il libro di Judith Bishop è abbastanza buono.