Come fai a sapere quando utilizzare i modelli di progettazione?

Chiunque può leggere il libro GoF per sapere quali sono gli schemi di progettazione e come usarli, ma qual è il processo per capire quando un modello di progettazione risolve un problema? La conoscenza del modello guida il design, o c’è un modo per capire come un modello può essere usato per cambiare un disegno?

In altre parole, ci sono modelli per Pattern?

I modelli di progettazione dovrebbero fornire una struttura in cui i problemi possano essere risolti. Quando si risolve un problema reale, è necessario considerare molte minuscole variazioni di una soluzione per quel problema per vedere se si adatta a uno schema di progettazione. In particolare, sarà probabilmente necessario generalizzare il problema, o la sua soluzione, al fine di adattare un modello di design.

La risposta è, è un’arte. Conoscere i modelli di progettazione è sicuramente un passo importante. Un modo per abituarsi a questo genere di cose è studiare le applicazioni dei modelli di progettazione, non solo i modelli. Vedere molte diverse applicazioni di un modello può aiutarti nel tempo a migliorare la mapping di un compito su un modello.

Consiglio vivamente la lettura di Head First Design Patterns da O’Reilly. Questo spiega come questi modelli possono essere usati nel mondo reale.

Head First Design Patterns

Aggiungo anche che non provare il design troppo con gli schemi in mente. Altro, cerca “odori di codice” che un modello potrebbe aiutare a risolvere.

Rivolgi la domanda: il modello che dovresti fare è “quale schema si adatta al mio problema”. Considera uno schema molto semplice, trovando un elemento in un array. in C, è qualcosa di simile

TYPE_t ary[SIZE] = // ... gets initialized somehow size_t ix ; // Your index variable for(ix=0; ix < SIZE; ix++){ if (ary[ix] == item) { return ix ; } } 

Non guardi il codice e pensi "dove posso usarlo?", Guardi il problema e dici "so come trovare un elemento in un array?"

Con modelli più estesi funziona davvero allo stesso modo. È necessario disporre di molte molte copie di una struttura dati che non cambiano spesso --- ciò ti fa pensare a "Flyweight". Vuoi qualcosa che vive su entrambi i lati di un confine di rete, pensi Proxy.

Quando studi i modelli, in particolare il GoF, chiedi a te stesso "in che situazioni si richiede questo modello? Ho visto questo modello in passato? Come avrei potuto utilizzarlo nel lavoro precedente? Dove posso trovare un esempio di questo nella mia vita? "

C’è un concetto fondamentale che sottende i modelli che la maggior parte delle persone non si lamenta. Non pensarli come strutture dati o algoritmi.

Invece, pensa al tuo codice come le persone che inviano messaggi, come passare le note o inviare lettere, a vicenda. Ogni object è una “persona”.

Il modo in cui organizzerai le “persone” e i modelli che usano per inviare messaggi l’un l’altro sono gli schemi.

Modelli di progettazione? Ti stai immergendo!

Non c’è niente di speciale nei modelli di design, sono solo modelli di design. Tutto lo sviluppo utilizza modelli di design. Esiste un certo insieme di schemi di progettazione nella programmazione orientata agli oggetti che sono considerati generalmente desiderabili e sono diventati i modelli di progettazione canonici. Ma ci sono anche molti schemi di design non desiderabili o comunque indifferenti (come gli anti-pattern di design ) come pure pattern non scoperti e / o non documentati.

Non è ansible evitare l’uso di schemi durante la programmazione. Ma puoi diventare più consapevole dei modelli che stai usando e di quando certi schemi sono utili e quando non lo sono. Studiare i modelli canonici di design del libro GoF aiuterà, così come lo imparerai a conoscere gli odori e il refactoring del codice . Non c’è una risposta giusta per quando un particolare design o modello di progettazione dovrebbe essere usato, è necessario accumulare esperienza nell’uso e nell’implementazione per sapere quando e dove usare quale modello.

Esperienza. Impara i modelli e gli esempi reali dei loro usi. Ogni volta che decidi di prendere una decisione sul design, pensa se un modello che conosci ti possa applicare. Col passare del tempo, si migliora e si scoprono nuovi modi per applicare i modelli a una più ampia gamma di problemi.

Un altro grande libro che ho trovato è stato:

Refactoring ai modelli

Mostrando quando, dove e come è ansible modificare il codice esistente in pattern, mi ha dato una migliore comprensione dei concetti e una capacità di identificare dove possono essere utilizzati.

Rian van der Merwe ha scritto un eccellente articolo su questo per Smashing Magazine nel giugno 2012. Ecco alcuni punti salienti.

Gli schemi di progettazione sono utili per due motivi:

  1. I pattern risparmiano tempo perché non dobbiamo risolvere un problema che è già stato risolto.
  2. I pattern rendono il Web più facile da usare perché, con l’aumentare dell’adozione tra i progettisti, gli utenti si abituano a come funzionano le cose, che a loro volta riducono il loro carico cognitivo quando incontrano elementi di progettazione comuni.

van der Merwe raccomanda di considerare la possibilità di rompere schemi quando:

  1. Il nuovo modo migliora empiricamente l’usabilità, o
  2. Il modo stabilito diventa obsoleto.

Come hai imparato quando usare una dichiarazione if?

Lo paragono a questo perché è un costrutto più grande di cui hai bisogno per conoscere i dettagli di prima che tu possa usarlo efficacemente. Un’istruzione if risolve una class di problemi che richiedono la ramificazione. Un modello a ponte risolve una class di problemi. Io davvero non li vedo in modo diverso.

Se conosci i modelli, allora diventano strumenti nella tua casella degli strumenti. Quando si guarda un’attività, si seleziona dai propri strumenti. A quel punto dovresti avere una buona idea di quale strumento sia la soluzione migliore per un determinato problema. Questo è il punto in cui le formule smettono di funzionare e in realtà fai lavori di ingegneria.

Sono d’accordo sul fatto che solo l’apprendimento dei modelli non è sufficiente. Il problema con la maggior parte dei libri è che non forniscono esempi reali. Ho sentito che Head First Design Patterns, come alcuni hanno suggerito in precedenza, è buono.

Un’altra cosa è che la maggior parte dei libri non sono intenzionalmente specifici della lingua , che potrebbe essere una buona o una ctriggers cosa per te. Per quanto sia importante capire un modello in generale, è altrettanto importante sapere come implementarlo bene . Mi sono imbattuto in un libro chiamato C # 3.0 Design Patterns che dedica quasi uguale inchiostro ad entrambi questi aspetti inseparabili.

Ho avuto questa stessa domanda quando ho incontrato per la prima volta gli schemi di progettazione. Ho apprezzato i concetti, ma non sapevo quando o come applicarli. Il mio approccio iniziale era di cercare l’applicabilità durante la fase di progettazione. Una volta che hai uno schema a blocchi e responsabilità semi-chiare per ogni blocco, non è troppo difficile prendere le responsabilità e incrociarle con un libro di riferimento decente. Alcuni buoni sono stati menzionati qui, ma quello di GoF dovrebbe essere nella tua lista. Il prossimo passo è cercare miglioramenti nel design basati su ciò che vedi nei modelli.

Il concetto di un modello di progettazione è stato preso dall’ingegneria strutturale, come con molte pratiche nell’ingegneria del software. Se si considera la costruzione di una struttura, è necessario prendere decisioni su come build quella struttura per raggiungere gli obiettivi stabiliti. Quando prendi queste decisioni, avrai una serie di requisiti da cui lavorare. Potrebbe essere qualcosa di semplice come Bridge deve essere in grado di supportare X tonnellate contemporaneamente, o avere una particolare resistenza alla trazione per consentire un sufficiente movimento nel vento, ecc. Un architetto userebbe la precedente conoscenza di altre build per fare quelle scelte progettuali. Sarebbe molto improbabile che provi a risolvere il problema da zero.

I modelli di ingegneria del software e di design sono esattamente gli stessi. Sono semplicemente soluzioni comuni a problemi comuni. Se si conoscono gli schemi di progettazione, quando si lavora in un progetto e una parte particolare di un sistema richiede qualcosa che si adatta a un modello di progettazione che si possiede, quindi utilizzarlo. Non provare ad adattare un sistema attorno a un modello di progettazione, adattare i modelli di progettazione al tuo sistema (dove si adattano). Basta provare a considerarli come un insieme di soluzioni per ridurre la quantità di lavoro di progettazione che è necessario fare, e sii cauto nel sovra-ingegnerizzare le tue soluzioni per stipare il maggior numero ansible di schemi di progettazione. Questo servirà solo a rendere la tua soluzione non gestibile e probabilmente piuttosto buggy.

Un modello di progettazione è una descrizione generica su come risolvere un problema comune . Ci sono 2 cose a cui dovremmo prestare attenzione:

Innanzitutto, è una descrizione generica ; non è la soluzione concreta, e nemmeno una ricetta completa, è solo una descrizione di come sarebbe la soluzione per affrontare un problema comune.

In secondo luogo, il problema è la domanda è un problema comune: significa che questo problema è stato riscontrato molte volte prima e nel tempo le persone hanno sviluppato una descrizione su come una soluzione ideale può essere applicata a questo problema comunemente ripetuto.

Quindi, se stai incontrando un nuovo problema che non è comune, cerca di non utilizzare modelli di progettazione per risolverlo, o almeno non creare modelli di progettazione come il tuo strumento per risolvere qualsiasi tipo di problema.