Scegliere il giusto modello di design

Ho sempre riconosciuto l'importanza di utilizzare modelli di progettazione. Sono curioso di sapere come gli altri sviluppatori scelgono quello più appropriato. Usi una serie di caratteristiche (come un diagramma di flusso) per aiutarti a decidere?

Per esempio:

Se gli oggetti sono correlati, ma non vogliamo specificare una classe concreta, si consideri Abstract

Quando l'istanza è lasciata alle classi derivate, considerare Factory

È necessario accedere in sequenza agli elementi di un oggetto aggregato, provare Iterator

o qualcosa di simile?

Un malinteso chiave nel mondo dei codici di oggi è che i modelli sono elementi costitutivi. Prendi un AbstractFactoryqui e un Flyweightlà e forse un Singletonlaggiù e li connetti insieme a XML e presto, hai un'applicazione funzionante.

Loro non sono.

Hmm, non era abbastanza grande.

I modelli non sono elementi costitutivi

Va meglio.

Un modello è qualcosa che usi quando scopri di avere un problema: hai bisogno di una certa flessibilità che fornisce il modello o che ti sei imbattuto quando stai creando una piccola lingua nel file di configurazione e dici "aspetta un momento, fermati, questo è il suo interprete che sto scrivendo - questo è un problema noto e risolto, usa un modello Interprete ".

Ma nota lì, che è qualcosa che scopri nel tuo codice, non qualcosa con cui inizi. I creatori di Java non hanno detto "Oh, metteremo un Flyweight in the Integer" all'inizio, ma piuttosto hanno realizzato un problema di prestazioni che potrebbe essere risolto da un flyweight .

E quindi, non esiste un "diagramma di flusso" che usi per trovare lo schema giusto. Il modello è una soluzione a un tipo specifico di problema che è stato riscontrato più volte e le sue parti chiave sono state distillate in un modello.

Iniziare con il modello è come avere una soluzione e cercare un problema. Questa è una brutta cosa: porta a un eccesso di ingegneria e, in definitiva, alla mancanza di flessibilità nel design.

Mentre scrivi il codice, quando ti rendi conto che stai scrivendo una Factory, puoi dire "ah ah! Quella è una fabbrica che sto per scrivere" e usare la tua conoscenza di conoscere il modello Factory per scrivere rapidamente il prossimo codice senza tentare di riscoprire il modello Factory. Ma non inizi con "Ho un corso qui, scriverò una fabbrica per farlo in modo che possa essere flessibile" - perché non lo farà.

Ecco un estratto da un'intervista a Erich Gamma (di Gamma, Helm, Johnson e Vissides ): Come usare i modelli di design :

Cercare di usare tutti i modelli è una cosa negativa, perché finirai con progetti sintetici, progetti speculativi che hanno flessibilità che nessuno ha bisogno. Al giorno d'oggi il software è troppo complesso. Non possiamo permetterci di speculare cos'altro dovrebbe fare. Dobbiamo davvero concentrarci su ciò di cui ha bisogno. Ecco perché mi piace il refactoring agli schemi. Le persone dovrebbero imparare che quando hanno un particolare tipo di problema o odore di codice, come la chiamano in questi giorni, possono andare alla loro casella degli strumenti dei modelli per trovare una soluzione.

Il miglior aiuto per "cosa usare, quando" è probabilmente la pagina di Wikipedia per il modello di progettazione del software - la sezione "Classificazione ed elenco" descrive la categoria in cui si trova ogni modello e cosa fa. Non c'è diagramma di flusso; la descrizione è probabilmente la migliore che troverai come frammento di "cosa usare quando".

Nota che troverai diversi schemi in diverse aree di programmazione. Il web design ha un proprio set di pattern mentre JEE (non il web design) ha un altro set di pattern. I modelli per la programmazione finanziaria sono completamente diversi da quelli per la progettazione dell'interfaccia utente dell'applicazione autonoma.

Quindi ogni tentativo di elencarli tutti è intrinsecamente incompleto. Ne trovi uno, scopri come usarlo e alla fine diventa una seconda natura e non devi pensare a come o quando usarlo mai più (fino a quando qualcuno ti chiederà di spiegarlo).

Mi chiedo:

1. Quale problema sto cercando di risolvere?
2. Quale modello di progettazione software (se presente) risolve più da vicino lo stesso problema o fornisce un percorso logico per risolverlo?
3. Ho bisogno dell'astrazione aggiuntiva (e della complessità) fornita dal modello o è un'ingegnerizzazione eccessiva per il mio problema specifico? Il problema può essere risolto in modo più semplice ed efficiente senza il modello?

Il processo di scelta di un modello software non è diverso dal processo di scelta di una struttura di dati, tranne per il fatto che nella scelta di una struttura di dati, si valuterebbero le prestazioni e le caratteristiche di memoria del problema e si sceglierebbe la struttura di dati più adatta a tali caratteristiche.