Come al solito

Dipende

Dipende da quanto OOP hai fatto per sapere se riconoscerai o addirittura sarai in grado di utilizzare gli schemi di progettazione

Dipende da quanto sei disciplinato sul fatto che applicherai i modelli una volta appresi correttamente, e non impazzire come un uomo proverbiale con un martello

D'altra parte ... cinque dita!

Se hai fatto un paio di anni di lavoro OOP serio o hai un mentore affidabile per tenerti sulla rotaia o ti piace proprio come leggere OOP-nerd , quindi con tutti i mezzi, compra il libro e studialo.

Aiuta a conoscere i pattern in modo che tu possa riconoscere quando usarli e quando non li usi.

Sì, dovresti impararli.

È ancora più sensato rivederli dopo aver acquisito un po 'di esperienza , in modo da poterli confrontare con ciò che sai. Per alcuni modelli si scoprirà che questo è qualcosa che hai scoperto da solo, ma imparerai qualcosa di più generale sul suo utilizzo, compromessi, varianti e così via. Altri potrebbero sembrare che si occupino direttamente dei problemi affrontati e mostrino una soluzione elegante che non conoscevi.

La grande maggioranza dei pattern è molto utile e comune . Gli altri potrebbero non essere così popolari, ma hanno ancora un uso limitato dove sono perfetti.

C'è ancora un motivo per cui vale la pena leggerlo: Ti insegnerà a pensare . Certo, non è un proiettile d'argento, ma un'ispirazione inestimabile.

Ultimo ma non meno importante, mai e poi mai, in nessuna circostanza, cerca di risolvere un problema con uno schema o uno strumento . È un pensiero molto cattivo e pericoloso! Comprendi come funziona lo strumento e usalo saggiamente per affrontare il problema, mai al contrario.

Più strumenti conosci bene, meglio è. A volte uno strumento può ispirare il tuo pensiero (piuttosto che risolvere direttamente un problema), un'altra volta ne combinerai alcuni per una soluzione eccezionale.

Il libro GOF è un'ottima fonte di molti strumenti utili che utilizziamo quotidianamente .

Il vantaggio più importante della conoscenza di Design Patters è che sai cosa significano i termini. In altre parole conosci il vocabolario comune .

Questo è, per me, il risultato più importante di tutte le turbolenze dei Pattern Design, che è nato un vocabolario comune in cui puoi semplicemente usare i nomi dei pattern specifici, e altri immediatamente sanno di cosa stai parlando senza che tu abbia per spiegarlo. Le cose che descrivono i pattern sono ben note alla maggior parte dei programmatori, ma ci vuole tempo per spiegare cosa intendi per gli altri, quindi rende la comunicazione più facile conoscere i nomi dei pattern.

Gli esempi sono Visitor, Singleton e Decorators.

Quindi, in altre parole, ti suggerisco di familiarizzare con i nomi e con quello che fanno.

SÌ ma con cautela!

La parte YES:

A volte, abbiamo riscontrato problemi nei nostri progetti. A volte questi problemi sono molto comuni, quindi un modello di progettazione offre soluzioni ben collaudate per questi problemi. I principali vantaggi dell'apprendimento dei modelli di progettazione è che puoi trovare una soluzione di design molto più veloce e se i tuoi colleghi sono a conoscenza del modello di progettazione gergo , puoi spiega anche una soluzione molto più veloce.

La parte con cautela:

I modelli di design non dovrebbero essere il santo graal delle tue soluzioni. La soluzione più semplice (KISS) è più desiderata e molte volte i modelli di progettazione renderanno le cose più complesse. Se stai imparando i modelli di progettazione, impara anche su anti-pattern. Conosco alcuni vecchi che sono contrari ai pattern di progettazione e sono d'accordo in qualche misura con loro perché quando non hai troppa codifica esperienza ma carica della teoria dei pattern di progettazione, potresti finire per renderti molto più difficile per te e il tuo team.

Infine, non pensare di dover adattare / modificare la tua soluzione solo per rispettare un modello di progettazione. Al contrario, puoi piegare uno schema di progettazione in modo che possa adattarsi alla tua soluzione. Va bene se non utilizzi tutti gli ingredienti di una ricetta di design pattern finché hai una soluzione migliore per il tuo particolare problema. Pensa ai modelli di design come a un suggerimento e non come regola per la tua soluzione.

Ho trovato il modo di pensare i pattern di Net Obiettivi come più vantaggioso. Le persone che leggono il libro GoF troppo spesso iniziano ad assumere che le strutture che mostrano, nella notazione del design e nel codice, sono i modelli e che questo è sempre il loro aspetto. C'è un modo diverso, probabilmente migliore di guardarlo.

I pattern sono insiemi di problemi simili che possono essere risolti con determinate formule astratte, non con set di formule che possono essere usati per risolvere vari problemi. Ciò significa che lo schema è già lì prima ancora di iniziare a provare a creare un disegno, l'oggetto quindi del designer è trovarlo , non imporlo.

Inoltre, molte persone guardano i modelli e dicono: "Oh, l'ho appena risolto da ... Non ho usato schemi non sciocchi". Il fatto è che "...." descrive quasi inevitabilmente un'implementazione di una determinata soluzione di pattern. Ad esempio, una serie di indicatori di funzione potrebbe fungere da catena di responsabilità anche se questo non è ciò che la ricetta tradizionale assomiglia.

Con questo in mente, l'attenzione nello studio dei modelli dovrebbe essere sui problemi, non sugli schemi. Impara i fattori motivanti dei modelli e come affrontano questi fattori. Questo ti permetterà di vedere gli schemi nel problema e poi semplicemente indicarli. Questo, insieme al linguaggio che i pattern ci offrono per parlare di design, ti consente di esporre un design adatto a rispondere alle varie difficoltà che stai affrontando.

SÌ, in breve, gli schemi di apprendimento non solo ne valgono la pena ... ti limiti a NON impararli. Non voglio dover descrivere tutti i principi motivanti e la forma generale della soluzione quando dico "Sembra un visitatore per me".

Ecco il loro sito web: link

I modelli di progettazione descritti da GoF sono una sorta di estensione naturale del paradigma OO. Se non comprendi a fondo gli obiettivi di OOP (incapsulamento, separazione delle preoccupazioni, principio di DRY, modularità, ecc.), Allora provare ad applicare i Design Pattern con successo non ha molto senso.

Se, tuttavia, ti bagnano i piedi nell'OOP del mondo reale e cerchi di essere fedele ai valori OOP, inevitabilmente entrerai in situazioni come quelle descritte dal GoF, e probabilmente avrai inventato soluzioni simili a il loro. Avendo risolto molti problemi simili, potresti iniziare a vedere emergere dei modelli; a questo punto, ha senso leggere il libro; idealmente, avrai un senso di riconoscimento e apprezzerai immediatamente l'eleganza e la pulizia dei modelli proposti. È probabile che prenderai in considerazione anche alcuni di questi modelli senza cervello (che, una volta che li conosci, molti di loro lo sono). Sarai anche in grado di giudicare bene se un determinato schema è applicabile o meno in una data situazione.

Ed ecco un altro avvertimento: solo perché conosci tutti questi schemi non significa che devi applicarli ovunque. Alcuni di loro sono abbastanza intelligenti, e la gente è tentata di usarli anche quando sono orribilmente inappropriati, il modello di Singleton è l'esempio più famoso (gran parte della controversia di Singleton deriva da un uso inappropriato, ad esempio quando non c'è alcun vantaggio nell'avere uno -instance-only constraint).

I modelli di progettazione cercano di risolvere i problemi del design.

• Sono stati creati AFAIK principalmente per le lingue OOP.
• Alcuni dei problemi non esistono nella programmazione funzionale (Command Pattern è come fare le funzioni di prima classe, Strategy Pattern approssima la funzione di ordine superiore ...). Questi pattern sono per le lingue (principalmente OOP) che non hanno funzionalità necessarie.
• Sono ordinati alfabeticamente. Diversi modelli sono la composizione di altri o le idee sono composte da quelle che c'erano prima.

Ho imparato i pattern più tardi, dopo aver conosciuto alcune funzioni di programmazione, UML, database desing, strutture dati e algoritmi. In realtà ho appena consultato la lista di design di questi modelli sul cheatsheet e annuito che io già conosco la maggior parte di loro. Alcuni erano davvero piacevoli come modelli singoli o "di comunicazione" (visitatore, mediatore) ...

Sono d'accordo con i punti formulati in diverse altre risposte su come può essere pericoloso applicare modelli di progettazione con poca esperienza.

Comunque, consiglio vivamente di leggere almeno il primo capitolo del libro dei GoF. La prima sezione ti introdurrà a progettare modelli, ma è molto più sui principi del design OO, e questo dovrebbe essere utile per leggere e capire anche con relativamente poca esperienza. (Alcune idee chiave che ricordo includono "incapsulare i concetti che variano", "le gerarchie di ereditarietà dovrebbero essere ampie ma non profonde"). È quasi un peccato che il lavoro sia noto soprattutto per i suoi 23 modelli - la sua discussione sui principi di progettazione OO quello che ha informato questi modelli è anche estremamente prezioso.

My question is, is it worth learning the patterns in the GoF book?

Assolutamente! Dovresti imparare non solo i modelli di progettazione del software, ma le tecniche di progettazione in generale. Imparare soluzioni comuni a problemi comuni è un inizio fantastico. Soprattutto una volta che inizi a scavare nei modelli e nei loro compromessi.

Do they show up enough that I should be learning them?

Il libro originale Gang of Four è stato sviluppato esaminando molti progetti software e vedendo le tecniche che un certo numero di sviluppatori ha usato per risolvere i problemi. Gli autori hanno notato alcune tecniche veramente buone, così come un numero che è stato applicato in progetti molto disgiunti e ha lavorato per renderle ancora più astratte da usare indipendentemente dal dominio.

it's always seemed counter-intuitive to try and make a problem fit a classic pattern

Questo è un grosso problema. Non si crea un problema per la soluzione. Invece, il libro dei modelli di progettazione Gang of Four ha una sezione "problema" per ciascun modello, mentre altri cataloghi di modelli hanno sezioni simili, che descrivono quando è necessario applicare ciascun modello. Descrive anche le "conseguenze" dell'uso del modello - se stai cercando di evitare una conseguenza, allora usare il modello non è la migliore idea.