Quindi è un po 'strano fare due domande back-to-back, ma non sono molto correlate e non volevo combinarle, ma non sto facendo spamming, lo prometto!

Ad ogni modo, sono un neolaureato recente e la mia educazione ha toccato solo i modelli di progettazione ... ne abbiamo implementati alcuni semplici, abbiamo toccato il fatto che ce ne fossero di più complicati e ci è stato chiesto di passare al libro del GoF se volevo saperne di più. La mia domanda è: vale la pena imparare gli schemi nel libro GoF? A me è sempre sembrato controintuitivo provare a far rientrare un problema in uno schema classico, ma ovviamente il libro e gli schemi sono famosi per un motivo. Si mostrano abbastanza che dovrei impararli?

Grazie ancora!

Come di solito

Dipende

Dipende da quanto OOP hai fatto sul riconoscimento o sulla capacità di utilizzare i modelli di progettazione

Dipende da quanto sei disciplinato sul fatto che applicherai gli schemi una volta appreso correttamente e non impazzire come il proverbiale uomo con un martello

D'altra parte ... cinque dita!

Se hai fatto un paio di anni di serio lavoro in OOP o hai un mentore affidabile per tenerti sui binari o ti piace leggere OOP-nerd, allora vai a comprare il libro e studiarlo.

Aiuta a conoscere i modelli in modo da riconoscere quando usarli e quando non usarli.

Sì, dovresti impararli.

Ha ancora più senso rivederli dopo aver acquisito esperienza , in modo da poterli confrontare con ciò che conosci. Per alcuni schemi si scoprirà che questo è qualcosa che hai scoperto tu stesso, ma imparerai qualcosa di più generale sul suo utilizzo, compromessi, varianti e così via. Altri potrebbero apparire per affrontare direttamente i problemi che hai affrontato e mostrarti una soluzione elegante che non conoscevi.

La grande maggioranza dei modelli è molto utile e comune . Altri potrebbero non essere così popolari, ma hanno ancora un uso ristretto dove si adattano perfettamente.

C'è un'altra ragione per cui vale la pena leggere: ti insegnerà come pensare . Certo, non è un proiettile d'argento, ma comunque un'ispirazione inestimabile.

Ultimo ma non meno importante, mai, mai, in nessun caso provare a far corrispondere un problema a un modello o uno strumento . È un pensiero molto brutto e pericoloso! Comprendi come funziona lo strumento e usalo saggiamente per affrontare il problema, mai viceversa.

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 un'ottima soluzione.

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

Il vantaggio più importante di sapere un po '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 di Design Patterns, che è emerso un vocabolario comune in cui puoi semplicemente usare i nomi dei modelli specifici e altri sanno immediatamente di cosa stai parlando senza che tu debba spiegarlo . Le cose che i modelli descrivono sono ben note alla maggior parte dei programmatori, ma ci vuole tempo per spiegare cosa intendi per altri, quindi rende più semplice la comunicazione dei nomi dei modelli.

Esempi sono Visitatore, Singleton e Decoratori.

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

SÌ ma con cautela!

La parte SÌ:

A volte, abbiamo riscontrato problemi nei nostri progetti. A volte questi problemi sono molto comuni, quindi uno schema di progettazione offre soluzioni ben collaudate per tali problemi. I principali vantaggi dell'apprendimento dei modelli di progettazione sono che puoi trovare una soluzione di progettazione molto più rapidamente e se i tuoi colleghi sono consapevoli del gergo del modello di progettazione , puoi anche spiegare una soluzione molto più rapidamente.

La parte cauta:

I modelli di progettazione 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 modelli di progettazione, scopri anche gli anti-schemi. Conosco alcune persone anziane che sono contrarie ai modelli di progettazione e concordo in qualche misura con loro perché quando non hai troppa esperienza di programmazione ma carico di teoria dei modelli di progettazione, potresti finire per rendere le cose molto più difficili per te e il tuo squadra.

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

Ho trovato il metodo di Net Objectives di pensare agli schemi come il più utile. Le persone che leggono il libro GoF troppo spesso iniziano a presumere che le strutture che mostrano, nella notazione di progettazione e nel codice, siano gli schemi e che sia sempre così. C'è un modo diverso, probabilmente migliore per vederlo.

I modelli sono insiemi di problemi simili che possono tutti essere risolti con determinate formule astratte, non insiemi di formule che possono essere utilizzati per risolvere vari problemi. Ciò significa che il modello è già lì prima ancora che tu inizi a provare a creare un disegno, l'oggetto del designer è quello di trovarlo , non di imporlo.

Inoltre, molte persone guardano gli schemi e dicono: "Oh, l'ho appena risolto da ... Non ho usato schemi stupidi". Il fatto è che "...." quasi inevitabilmente descrive un'implementazione di una data soluzione di modello. Ad esempio, una serie di puntatori a funzioni potrebbe fungere da catena di responsabilità anche se non è l'aspetto della ricetta tradizionale.

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

SÌ, in breve, i modelli di apprendimento non valgono solo la pena ... ti limiti a NON impararli. Non voglio descrivere tutti i principi motivanti e la forma generale della soluzione quando dico "Mi sembra un visitatore".

Ecco il loro sito Web: http://www.netobjectives.com/PatternRepository/index.php?title=Main_Page

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

Se, tuttavia, ti bagnerai i piedi nella OOP del mondo reale e provassi a essere fedele ai valori di OOP, ti imbatterai inevitabilmente in situazioni come quelle descritte dal GoF e probabilmente inventerai soluzioni simili alle loro. Avendo risolto molti problemi simili, potresti iniziare a vedere emergere degli schemi; a questo punto, ha senso leggere il libro; idealmente, avrai un senso di riconoscimento e apprezzerai immediatamente l'eleganza e la pulizia dei motivi proposti. È probabile che considererai anche alcuni di questi schemi senza cervello (che, una volta conosciuti, molti di loro sono). Sarai anche in grado di giudicare bene se un determinato modello è applicabile o meno in una determinata situazione.

Ed ecco un altro avvertimento: solo perché conosci tutti questi schemi non significa che devi applicarli ovunque. Alcuni di loro sono piuttosto intelligenti e le persone sono tentate di usarli anche quando sono orribilmente inadeguate, il modello Singleton è l'esempio più famoso (gran parte della controversia di Singleton deriva da un uso inappropriato, ad esempio quando non vi è alcun vantaggio nel possederne uno -il vincolo solo istanza).

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

• Sono stati creati AFAIK principalmente per le lingue OOP.
• Alcuni problemi non esistono nella programmazione funzionale (il modello di comando è come creare funzioni di prima classe, il modello di strategia si avvicina alla funzione di ordine superiore ...). Questi schemi sono per le lingue (principalmente OOP) che non hanno bisogno di funzionalità.
• Sono ordinati alfabeticamente. Diversi schemi sono composti da altri o le idee sono composte da quelle che c'erano prima.

Ho imparato i modelli in seguito, dopo aver appreso alcuni programmi funzionali, UML, progettazione di database, strutture di dati e algoritmi. In realtà sono appena passato all'elenco dei disegni di questi motivi sul cheatsheet e ho annuito che ne conosco già la maggior parte. Alcuni erano davvero carini come schemi singleton o "comunicativi" (visitatore, mediatore) ...

Concordo con i punti formulati in molte altre risposte su come può essere pericoloso applicare modelli di progettazione con poca esperienza.

Consiglio vivamente di leggere almeno il primo capitolo del libro GoF. La prima sezione ti introdurrà ai modelli di progettazione, ma riguarda davvero i principi della progettazione di OO e questo dovrebbe essere utile da leggere e comprendere anche con relativamente poca esperienza. (Alcune idee chiave che ricordo includono "incapsulare i concetti che variano", "le gerarchie ereditarie dovrebbero essere ampie ma non profonde".) È quasi un peccato che il lavoro sia noto principalmente per i suoi 23 modelli: la sua discussione sui principi di progettazione OO che ha informato quei modelli è anche estremamente prezioso.

La mia domanda è: vale la pena imparare gli schemi nel libro GoF?

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 negli schemi e nei loro compromessi.

Si mostrano abbastanza che dovrei impararli?

Il libro originale Gang of Four è stato sviluppato esaminando molti progetti software e vedendo le tecniche utilizzate da numerosi sviluppatori per risolvere i problemi. Gli autori hanno notato alcune tecniche davvero valide, nonché un numero che sono stati applicati in progetti molto disgiunti e hanno lavorato per astrarli ancora di più per essere utili indipendentemente dal dominio.

è sempre sembrato controintuitivo provare a far rientrare un problema in un modello classico

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