Un malinteso chiave nel mondo della codifica di oggi è che i modelli sono elementi costitutivi. Prendi un AbstractFactory qui e un Flyweight lì e forse un Singleton laggiù e collegali insieme a XML e presto, hai un'applicazione funzionante.
Non lo sono.
Hmm, non era abbastanza grande.
I pattern non sono blocchi predefiniti
È meglio.
Un pattern è qualcosa che usi quando trovi che hai un problema - hai bisogno di una certa flessibilità che il pattern fornisce, o che sei inciampato quando stai facendo una piccola lingua nel file di configurazione e tu dire "aspetta un momento, fermati, questo è il suo interprete che sto scrivendo - questo è un problema noto e risolto, usa un Interprete modello ".
Ma nota che è qualcosa che scopri nel tuo codice, non qualcosa con cui inizi. I creatori di Java non hanno detto "Oh, inseriremo un Flyweight nell'Inter" all'inizio, ma abbiamo realizzato un problema di prestazioni che potrebbe essere risolto da un mosca .
E quindi, non esiste un "diagramma di flusso" che usi per trovare il modello giusto. Il pattern è una soluzione per un tipo specifico di problema che è stato riscontrato ancora e ancora e le sue parti principali sono state distillate in un Pattern.
Iniziare con il Pattern è come avere una soluzione e cercare un problema. Questa è una brutta cosa: porta a un eccesso di ingegnerizzazione e, in definitiva, all'inflettibilità nel design.
Mentre scrivi il codice, quando realizzi che stai scrivendo una fabbrica, puoi dire "ah ah! questa è una fabbrica che sto per scrivere" e usare la tua conoscenza del modello Factory per scrivere rapidamente prossimo bit di codice senza provare a riscoprire il modello di fabbrica. Ma non inizi con "Ho una lezione qui, scriverò una fabbrica per questo in modo che possa essere flessibile" - perché non lo farà.
Ecco un estratto da un'intervista con Erich Gamma (di Gamma, Helm, Johnson e Vissides ): Come utilizzare i modelli di progettazione :
Trying to use all the patterns is a bad thing, because you will end up with synthetic designs—speculative designs that have flexibility that no one needs. These days software is too complex. We can't afford to speculate what else it should do. We need to really focus on what it needs. That's why I like refactoring to patterns. People should learn that when they have a particular kind of problem or code smell, as people call it these days, they can go to their patterns toolbox to find a solution.
Il miglior aiuto per "cosa usare, quando" è probabilmente la pagina di Wikipedia per modello di progettazione del software - il La sezione "Classificazione ed elenco" descrive la categoria in cui si trova ciascun modello e che cosa fa. Non c'è un diagramma di flusso; la descrizione è probabilmente la migliore che troverai come un breve frammento per "cosa usare, quando".
Nota che troverai diversi modelli in diverse aree di programmazione. Il Web design ha il 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 stand alone.
Quindi qualsiasi tentativo di elencarli tutti è intrinsecamente incompleto. Ne trovi uno, comprendi come usarlo e poi alla fine diventa una seconda natura e non hai bisogno di pensare a come o quando usarlo mai più (fino a quando qualcuno ti chiede di spiegarlo).