Quando dovrei usare - e non usare - modelli di progettazione? [duplicare]

KISS prima, modelli più tardi, forse molto più tardi. Un modello è uno stato mentale, per lo più. Non provate mai a forzare il vostro codice in uno schema specifico, piuttosto notate quali modelli iniziano a cristallizzarsi dal vostro codice e ad aiutarli un po '.

Decidere "ok, sto per scrivere un programma che fa X usando il pattern Y" è una ricetta per il disastro. Potrebbe funzionare per ciao programmi di classe mondiale adatti a dimostrare i costrutti di codice per i pattern, ma non molto di più.

Penso che la preoccupazione principale sia rappresentata dal fatto che le persone spesso hanno la tendenza ad abusare dei modelli di progettazione. Ne imparano alcuni, ne vedono l'utilità e senza rendersene conto trasformano quei pochi modelli in una sorta di martello d'oro che poi applicano a tutto.

La chiave non è necessariamente per imparare i modelli stessi. La chiave è imparare a identificare gli scenari e i problemi che i modelli devono affrontare. Quindi applicare il modello è semplicemente una questione di utilizzare lo strumento giusto per il lavoro. È il lavoro che deve essere identificato e compreso prima che lo strumento possa essere scelto.

E a volte è una configurazione strana e non esiste un modello tagliato e asciutto per risolverlo immediatamente. A quel punto occorre dedicare più attenzione al problema piuttosto che alla soluzione. Suddividilo in problemi di componenti, identifica le aree del problema che condividono tratti comuni con problemi indirizzati da modelli noti, regola i modelli per adattarli al problema, ecc.

Un modello di progettazione funziona meglio quando viene utilizzato come linguaggio comune nel tuo team.

Con ciò intendo, puoi dire qualcosa come "questa classe è un Singleton che implementa il nostro IHairyWidget Fabbrica astratta " e tutti i membri del tuo team comprendono ciò che significa senza dover entrare in spiegazioni dettagliate.

Dove falliscono i modelli di progettazione è quando il team non li capisce, o quando sono abusati così tanto che smettono di rendere il progetto più chiaro e invece rendono più difficile capire cosa sta realmente accadendo.

forse un po 'fuori tema, ma penso che riguardi anche la tua domanda: ti suggerirei un buon libro Refactoring to Patterns :

This book introduces the theory and practice of pattern-directed refactorings: sequences of low-level refactorings that allow designers to safely move designs to, towards, or away from pattern implementations. Using code from real-world projects, Kerievsky documents the thinking and steps underlying over two dozen pattern-based design transformations. Along the way he offers insights into pattern differences and how to implement patterns in the simplest possible ways.

troverai esempi in cui i modelli di progettazione sono buoni da usare, così come quando devi andare via da loro, non per rendere l'applicazione più complicata. E sì, l'idea principale è di mantenere tutto il più semplice possibile.

Buona risposta / consiglio alla tua domanda era nell'articolo Riconosci i 4 segni premonitori di design pattern Abuse? , ma non riesco a caricarlo ora, errore 500. Non è grande, quindi ho appena usato la cache di google per ottenerlo :

Software design patterns can and do lead to over-engineering

Over-engineering is the process of over complicating something. In the case of programming, making your code more complex and possibly more flexible than it needs to be. More specifically, implementing complex software design patterns on simple problems.

1. Start simple not complex

How does this happen? Usually you program in extra functionality that you anticipate will be used or prove to be useful later. But what happens if this need never materialises? In most cases, the cruft gets left there. It doesn’t get removed. So the software system continues to grow in size and complexity with all these features that aren’t ever being used.

2. Be wary of the signs

This is perhaps different for everyone but I suspect in most cases, it isn’t really a conscious effort. But rather, it is something brought about by the fear of being stuck with an awkward, inelegant, inappropriate or simply put, bad design; being stuck with something that just isn’t flexible enough. Ironically, if you get to the point of over engineering or over applying patterns you are right back where you started.

Software design patterns appeal to programmers or developers because they allow them to naturally express and create beautiful architectures. It's a part of enjoying creative programming.

3. Consider refactoring to a pattern rather than starting from one

What might be a good way to avoid this design pattern abuse? Consider refactoring to a pattern rather than starting from one. Don’t start out trying to force a pattern into your design. Chances are your design could be much simpler without it. If you do find at a later stage that your design truly could benefit from a structured pattern, then refactor to allow for it. When you design, solve the problem in the simplest way possible. Simple light weight software is always a good thing. There are better ways of avoiding the under-engineered alternative where you get stuck with a design or solution that just isn’t flexible enough or doesn’t suit the problem.

4. Don’t force yourself to get it right the first time

Forcing software design patterns or structures into design just isn't the answer, that's just bad design. But prototyping or building an initial build0 (proof of concept build before production on the actual product begins) can help avoid this and the problem of over-engineering. Because you don't feel like you have to get it perfectly right the first time.

when to stop doing everything using patterns ?

La domanda è: quando hai iniziato a fare tutto usando i pattern? Non tutte le soluzioni si adattano perfettamente a uno schema di progettazione esistente e l'adozione di un modello può significare che infangate la pulizia della soluzione. Potresti scoprire che, invece del modello di progettazione che risolve il problema, generi un ulteriore problema cercando di forzare la soluzione per adattarla a un modello di progettazione.

Ovviamente, se scegli il modello di progettazione corretto per uno scenario particolare, non avrai alcun problema, tuttavia scegliere quello corretto è più facile a dirsi che a farsi.

Ho visto un uso eccessivo di modelli in progetti in cui non sono realmente necessari.

Penso che la chiave sia : cerca di mantenere il tuo codice pulito, modulare e leggibile e assicurati che le tue classi non siano strettamente accoppiato . Alla fine potresti vedere che hai inavvertitamente usato una variazione su un modello di progettazione standard. Forse l'avresti capito all'inizio del tuo progetto prima di iniziare a programmare. Se si codifica come la maggior parte delle persone che conosco (incluso me stesso), allora probabilmente no:)

Bene, la cosa più importante è conoscere il problema che stai risolvendo. Di quanto tu abbia bisogno di decidere se introdurre qualche schema ti darebbe dei vantaggi rispetto a non usarlo (guadagno su prestazioni, semplicità o altro). Domande correlate: link

Il n. dei modelli di design menzionati nel testo originale / di fatto del go-to sull'argomento, cioè GoF richiede un bel po 'di esperienza e spesso diverse riletture e brain-storming con colleghi competenti da padroneggiare. Posta quel palco, dato un problema, data un'architettura, spesso i modelli di progettazione più naturali escono in modo abbastanza ovvio. Tuttavia, qualsiasi tentativo di adattare forzatamente il modello di progettazione ai problemi, o di mappare i problemi ai modelli di progettazione è irto di pericoli, nel qual caso è meglio consultare esperti, infastidire un po 'e prenderlo come esperienza di apprendimento. A meno che non ti senta a tuo agio con i modelli di progettazione 10-dispari comunemente usati, questo rimarrà un po 'complicato, e AFAIK, non ci sono scorciatoie.

Sono venuto a conoscenza di milioni di progetti di codice SLOC C ++ con ampi esempi di modelli di progettazione con adattamento forzato, quindi errori s.a. l'uso eccessivo non è molto raro.

In genere va così con qualsiasi argomento che richiede di apprendere e applicare le regole :

1. Se sei un principiante, devi seguire le regole perché non lo sai meglio
2. Se sei un dilettante, segui i ruoli perché sai perché ne hai bisogno.
3. Se sei un professionista, lavori con le regole piuttosto che contro di esse, sapendo bene cosa usare dove e quando non si applicano.
4. Se sei un esperto, ignori le regole.
5. Se hai dominato la tua arte, preferisci le regole dato che il tuo codice deve essere visto anche dalle persone di categoria 1-3. :)

È lo stesso con le arti marziali, la pittura, la scrittura, il calcio, la meccanica, la guida, ecc. ecc.

Come quinto ragazzo, di solito finisci per insegnare ai ragazzi # 1-4 come diventare il top, quindi si applica sempre, anche in contesti competitivi.

( Come trascurare e ignorare le regole lo spiega in senso generale, ma ci sono probabilmente dei saggi migliori là fuori.)

La regola è che non esiste una regola. La tua esperienza (il successo più che i fallimenti) ti dirà quando usarli puramente, quando adattarli o quando non usarli affatto.

C'è una presentazione di Dan North in cui parla un po 'di apprendimento e schemi

Mantieni tutto il più semplice possibile. Tuttavia, per risolvere un problema, è preferibile utilizzare un modello di progettazione piuttosto che reinventare la ruota, poiché molti modelli di progettazione forniscono soluzioni a problemi comuni. Ma come ho detto: usali solo quando veramente necessario.

Forse usa il pattern KISS DRY SoC (sì, forse non è un pattern, ma suona divertente).

Keep It Simple, Stupid.
Non ripetere te stesso.
Separazione delle preoccupazioni.

Penso che questi tre punti dovrebbero essere di ispirazione per qualsiasi programmatore.

Il problema con i "pattern" è che qualsiasi cosa può essere considerata un pattern, e spesso lo è.

Da tempo sviluppavo il codice professionalmente per molto tempo prima che sentissi qualcuno parlare di "schemi", e sono riuscito bene per tutti quegli anni. In effetti, quando guardo indietro, molte delle cose che ho scritto in realtà hanno seguito alcuni dei modelli ben noti, almeno in una certa misura.

Il mio punto è che seguire rigidamente qualsiasi schema dato non è in realtà la risposta. Scopri nuovi modelli, ma non ti legare a loro: cambieranno. Le buone pratiche di codifica oggi non sono le stesse buone prassi di codifica dieci anni fa, e non importa quanto intelligenti siano i programmatori di oggi, puoi essere certo che a dieci anni di distanza, le cose considerate buone pratiche oggi saranno state superate.

Off topic: su una nota personale, odio davvero l'uso della parola "pattern" in questo contesto. Puzza di gergo non necessario.

Imho lo saprai e basta. Voglio dire, ho persino usato un modello di design prima di conoscere la definizione del modello di progettazione. È solo una buona codifica. A volte sarai in grado di riconoscerlo mentre scrivi i requisiti del progetto e a volte devi refactoring il tuo codice.

jwenting ha detto KISS prima, modelli più tardi . Penso che i pattern siano un modo per KISS di un progetto perché puoi applicare qualcosa che sai che funziona e risparmia il tuo tempo in futuro.

L'unica cosa che potrebbe andare storta è che ci sono molti modi per implementare un singolo modello di progettazione, anche nella stessa lingua, quindi devi capire completamente qual è il tuo problema .

Il modo in cui strutturi la logica del tuo codice dovrebbe consentire a un nuovo arrivato di quel codice di essere in grado di interpretarlo e modificarlo. Avere un modello solo perché è una buona pratica non ti porterà da nessuna parte se non comprendi pienamente il contesto di come, chi e dove quel codice è e potrebbe potenzialmente essere utilizzato.

Il pattern "Keep it simple" è più una cosa di buon senso che un pattern e deve essere una parte del processo di pensiero di uno sviluppatore durante la creazione del codice. Supponendo che ognuno abbia un particolare schema non è necessariamente corretto. Idealmente vuoi un modello che possa essere letto e identificato senza tanta conoscenza di esso.

Molto spesso i pattern di design sono usati per spiegare al pubblico più ampio cosa fa realmente il tuo codice. In questo modo è più facile per le persone capire cosa stai facendo. Raramente lo utilizza come riferimento per trovare soluzioni, poiché un modello può essere implementato in molti modi.