Quanto sono importanti i Pattern di progettazione?

Question

Quanto sono importanti i Pattern di progettazione?

Penso che la prima generazione di programmatori non usasse molto i modelli di progettazione (persone che si sono diplomate negli anni '80 e prima della metà degli anni '90). Il neolaureato lo sa in generale e lo usa molto di più?

Se siete interessati, ho anche fatto un indagine in ed è possibile visualizzare qui:

http://www.surveymonkey.com/s.aspx?sm=kJOdGX0RPx5FGrfPVm_2bmIw_3d_3d

Aggiornamento: Ecco i risultati del sondaggio iniziali:

http://img192.imageshack.us/img192/7107/surveyresults.png

Answer 1

Abbiamo utilizzato modelli di progettazione negli anni '80, non sapevamo che fossero modelli di progettazione.

Answer 2

L'unico grande vantaggio dei modelli di design a mio parere è che offre agli sviluppatori un vocabolario comune per parlare di soluzioni software.

Se dico "dovremmo implementarlo usando lo schema del singleton", abbiamo un punto di riferimento comune per iniziare a discutere se questa è una buona idea senza che io debba implementare la soluzione prima in modo da sapere cosa Intendo.

Aggiungete la leggibilità e la manutenibilità fornite con soluzioni familiari ai problemi più comuni, invece che ogni sviluppatore che tenta di risolvere il problema a modo suo più volte.

Abbastanza importante. Il software può essere fatto senza di loro, ma è sicuramente molto più difficile.

Answer 3

Non sono assolutamente necessari, ma il bene supera definitivamente il cattivo.

La buona:

1. la leggibilità del codice: Essi consentono di scrivere codice più comprensibile con i nomi migliori per ciò che si sta cercando di realizzare.
   • Manutenibilità del codice: Consente di mantenere il codice più semplice perché è più comprensibile.
   • Comunicazione: Aiutano a comunicare gli obiettivi di progettazione tra i programmatori.
   • Intenzione: Mostrano immediatamente l'intento del codice a qualcuno che sta imparando il codice.
   • Riutilizzo del codice: Ti aiutano a identificare soluzioni comuni a problemi comuni.
   • Meno codice: Essi consentono di scrivere meno codice perché una parte maggiore del codice può derivare funzionalità comuni dalle classi di base comuni.
   • Soluzioni testate e acustiche: La maggior parte degli schemi di progettazione sono testati, testati e affidabili.

---

La cattiva:

1. livelli extra di riferimento indiretto: forniscono un ulteriore livello di riferimento indiretto e, quindi, rendere il codice un po 'più complessa.
   • Sapere quando usarli: Sono spesso abusati e utilizzati in casi che non dovrebbero essere. Un compito semplice potrebbe non aver bisogno del lavoro extra di essere risolto utilizzando un modello di progettazione.
   • Diverse interpretazioni: Le persone talvolta hanno interpretazioni leggermente diverse dei modelli di progettazione. Esempio MVC visto da django vs MVC visto da Ruby on Rails.
   • Singleton: Devo aggiungere altro?

Answer 4

importante non è la parola che userei. Vorrei usare la parola "utile". Dare agli sviluppatori un linguaggio comune per descrivere problemi/soluzioni frequenti è utile - più in un ambiente collaborativo.

Answer 5

Ottima domanda! Mi stavo solo facendo questa domanda una settimana fa. Li uso ogni volta che posso, ma non trovo davvero molte opportunità per usarli. Personalmente penso che l'idea di Design Patterns sia fantastica. Gli ingegneri meccanici e gli ingegneri elettronici non progettano da zero, ma applicano schemi ben noti che, tra le altre cose, consentono ai neofiti di poggiare sulle spalle delle conoscenze dei loro predecessori. I design pattern sono un passo nella giusta direzione, ma sono necessari molti più passaggi.

Answer 6

Penso che manchi il punto su cosa sia un motivo di progettazione.

Nell'ingegneria del software, un modello di progettazione è una soluzione generale riutilizzabile per un problema comune nella progettazione del software.

Quindi progettare modelli sono solo un linguaggio formale per definire comuni modi per risolvere i problemi di ingegneria del software. Penserei che la maggior parte delle persone stia usando schemi di progettazione senza sapere che lo sono. Quindi queste soluzioni comuni ai problemi del software possono risalire a un lungo cammino, non avevano appena creato un linguaggio formale per descrivere cosa stavano facendo.

Penso che gli schemi di progettazione siano importanti perché ti insegnano i metodi di comando per risolvere i problemi nelle aree a cui si applicano i modelli di progettazione.

Answer 7

Gli schemi di progettazione vengono insegnati nelle classi di progettazione per CS. Non sono essenziali, ma davvero utili se riesci a trovare situazioni analoghe per avere una soluzione che è stata pensata.

Consente inoltre ai programmatori di comunicare più facilmente. Puoi parlare anche con il tuo collega in termini di modelli. Se tu dici qui ho il mio osservatore, quindi è abbastanza ben capito cosa sta succedendo.

Le persone troveranno naturalmente soluzioni che si adattano a un modello di progettazione per conto proprio, ma i modelli di progettazione aiutano a definire la terminologia e le idee standard che possono essere utili.

Non c'è niente di straordinario nei modelli, la cosa più bella è che sono idee canonizzate e definite in modi che sono ripetutamente utili.

Answer 8

direi molto

Il trucco con design pattern è apprendimento dove e quando li usare. Poi può fare un sacco di cose per voi come:

1. rendere il codice più leggibile
2. Lo rendono facile mantenere
3. renderlo più flessibile
4. E la lista continua ...

Ma a volte possono fare l'esatto contrario di alcuni dei benefici lì ancora una volta il suo sapere come e quando ...

Hai mai provato a tirare fuori un frammento con un martello per incorniciare? Si può amarti inquadrando il martello, ma la sua intenzione di causare problemi di ogni genere, se si tenta di utilizzare in questo modo ...

Penso che, come si refactoring si codifica a volte evolve in un particolare modello o si può avere ha usato un modello per tutto il tempo senza rendersene conto.

Answer 9

Personalmente, li considero ampiamente sovrastimato e del valore marginale. L'idea sembra grandiosa, ma quando ci si abbassa, c'è davvero solo una manciata che è abbastanza comune e utile da ricordare (e possibile ricordare).

Direi che il loro effetto netto è negativo, a causa della orribile sovrastampa perpetrata da persone recentemente innamorate del concetto e cercando di stipare quanti più modelli nel loro codice possibile. Forse ancora peggio è l'effetto Maslow's hammer che porta a un cattivo design perché invece di trovare quello ottimale, lo sviluppatore ha ricordato un modello di progettazione che si adatta (male).

Answer 10

I modelli software sono importanti se si sa che li si sta usando o meno ... per definizione.

Un modello di progettazione è semplicemente una soluzione generalizzata e riutilizzabile per un problema che si verifica comunemente.

È possibile modificare la situazione fino a quando non si reinventa la soluzione di ogni problema che si incontra o è possibile apprendere i "modelli" che i programmatori utilizzano da generazioni. Se formalizzi la tua conoscenza dei modelli più comuni e denominati, avrai un vocabolario comune per discutere e applicare le soluzioni.

godere,

Robert C. Cartaino

Answer 11

trovo design pattern di valore marginale. Qualsiasi framework di software ben organizzato e progettato ha centinaia di modelli di progettazione e pochissimi di essi sono descritti nella formale "letteratura di pattern".

Prima c'erano schemi di progettazione, c'era un software ben progettato che aveva molti modelli che potevano essere riutilizzati in molte situazioni. Ad esempio, il libro di Kernighan e Ritchie su C conteneva un esempio di calcolatrice implementato usando yacc e lex e uno stack, una tabella di simboli, un puntatore di funzione che passava (cioè un binding sostanzialmente dinamico) e conteneva un gran numero di pattern per la dimensione del libro.

Probabilmente si possono imparare centinaia di schemi di progettazione più utili studiando per es. Microsoft framework .NET, librerie di classi Java, ecc. Rispetto alla lettura di un libro su modelli di design.

In realtà, un buon software ha un design. E se il design è buono, probabilmente può essere riutilizzato. Voila: un modello di design.

Answer 12

Ho visto troppi casi di sindrome "Ragazzo piccolo con un modello". Di solito colpisce più duramente solo dopo che una persona ha letto per la prima volta il libro GoF e immediatamente scappa per vedere quanti di essi possono essere inseriti nel progetto su cui stanno lavorando. (Punti extra per includere tutti i 23 in un singolo progetto.) Si ritrovano con un sistema progettato per un pollice della sua vita e impossibile da capire o modificare.

Alla fine la febbre si rompe e si calmano abbastanza da usarli in modo appropriato. Ma il danno può essere grande.

Il punto di riferimento è il libro "Core Java EE Patterns". Elenca un sacco di cose che affronta le "migliori pratiche" per EJB 1.0 e 2.0 che ora sono considerate anti-pattern. Le specifiche EJB 3.0 ne eliminano molte. La primavera sta uccidendo il resto.

I modelli hanno avuto il loro giorno al sole, come UML. Ma il sole sta calando su entrambi. Non credo che nessuno dei due abbia salvato il mondo o sia stato liberato dall'hype.

Answer 13

Anche se a volte può essere utile parlare di schemi di progettazione, sono tendenzialmente d'accordo con coloro che li considerano dannosi in molte situazioni.

L'argomento principale che vorrei fare è che spesso impediscono alle persone di trovare soluzioni adeguate a un problema specifico. Invece di pensare a come risolvere quel particolare problema, le persone cercano di applicare uno schema di progettazione dopo l'altro.

Inoltre tendono a nascondere le carenze linguistiche. Molti di loro sono banali in una lingua abbastanza espressiva. Un primo esempio potrebbe essere il modello di strategia che sta sostanzialmente reinventando la programmazione funzionale in modo complicato. Spesso le persone starebbero meglio a capire i veri principi di programmazione invece di parlare solo con i linguaggi pattern.

Detto questo: preferisco parlare di schemi con qualcuno piuttosto che non avere un linguaggio comune. In questo modo sono importanti se non esiste un'opzione migliore. Se riesco a spiegarmi in modi più formali (ad esempio algebre), allora smetto di preoccuparmi dei linguaggi del modello. Certo, alcuni sostengono che ho appena inventato i miei linguaggi di pattern in questo modo ;-)

Answer 14

Direi che sono sicuramente importanti.

Tra i motivi tipici (vocabolario condiviso, non reinventare la ruota) sono un trampolino di lancio per l'apprendimento del buon design del software. La maggior parte dei modelli di progettazione là fuori inizia dai programmatori con un buon senso dei principi OO che applicano ciò che sanno per risolvere un problema e notano che altre persone stanno arrivando con la stessa soluzione. Se pensi ai modelli di design come a un libro di cucina per risolvere il problema attuale su cui sei bloccato, non sono davvero utili, ed è qui che vedi il "design pattern hammer" uscire e complicare i disegni.

Se invece si pensa a una finestra in una buona progettazione orientata agli oggetti, si inizia a vedere quanto sono preziosi, cioè pensando in base ai principi che stanno alla base dei modelli di progettazione invece degli specifici modelli di progettazione stessi.

Answer 15

Inizia con Principles prima di considerare Patterns, perché sono i principi di progettazione generali che informano e motivano l'emergere di schemi.

Per il tuo problema particolare, ti consigliamo di seguire i principi prima di tutto. Se arrivi a un Pattern noto allora, congratulazioni, hai appena riscoperto un Pattern, buono per te. Il problema è che potrebbe richiedere molto tempo, quindi dipende se si vuole rischiare di inventare alcuni anti-pattern lungo il percorso o se si desidera una scorciatoia per qualcosa che è già stato pubblicato. Consideralo però, perché imparerai di più che leggere la descrizione di qualcun altro del proprio lavoro.

Il lato negativo (come molte delle ottime risposte qui già evidenziate) è che si potrebbe essere tentati di applicare un Pattern pubblicato in un contesto in cui non si adatta o semplicemente non è garantito.

Un buon punto di partenza ai principi di progettazione è, cercando in Uncle Bob Martin's SOLID principles, la cosa bella di loro, una volta affondano in, è che ti senti come se già li conosceva (che ti fa sentire intelligente) e

Il libro di zio Bob Clean Code copre anche molti degli stessi principi con alcuni esempi utili, solo non citando esplicitamente i principi come articoli originali, concentrandosi maggiormente sull'organizzazione e sul riordino delle funzioni, delle classi, ecc.

Answer 16

commentato Modelli di progettazione sono utili se stai cercando di contribuire a progetti open source ... abbastanza detto!