Qualche suggerimento per un corso accelerato sui modelli di progettazione?

Question

Ho intenzione di dare agli sviluppatori della mia azienda un corso accelerato sui modelli di progettazione (dopo aver trovato un codice spaventoso di recente).

Una delle cose più importanti che voglio trasmettere è che risparmiano tempo sia a lungo che a breve termine (cosa che fanno davvero!) - visto che gli sviluppatori qui sono sottoposti a un po 'di tempo. Tutto sommato ho bisogno di dimostrare i benefici quotidiani - cose che li lasceranno andare presto a casa.

Dire loro che potrebbe significare che meno errori probabilmente non colpiranno a casa. Ho bisogno di cose che stanno per affondare.

Probabilmente farò tre o quattro sessioni di un'ora ciascuna. Avete qualche suggerimento su cosa toccare/fare?

Answer 1

Buone diapositive di apertura per qualsiasi corso di formazione a mio parere sono:
1) Perché siamo qui? (Dove è stata identificata la necessità di questo corso?)
2) Che cosa mi aspetto di apprendere?
3) Chi dovrebbe seguire questo corso? (Quali sono gli studenti previsti, i prerequisiti, ecc.)
4) Quando posso applicare ciò che ho imparato?
5) aspettative di voi (Partecipazione, compiti a casa, test, lezioni minimi per partecipare, ecc)

Per design pattern potevo aspettarmi diversi strumenti visivi o "job aids".

vorrei seguire uno struttura simile alla Elements of Reusable Object-Oriented Software libro:

1) UML - Class Diagram Panoramica
2) OOP - astrazione, incapsulamento, polimorfismo, ereditarietà
3) coesione e accoppiamento
4) Cos'è un motivo di design? - Nome del modello, Il problema, La soluzione, Le conseguenze
5) Perché i modelli di progettazione sono così difficili da imparare?
6) Perché utilizzare i modelli di progettazione?
7) Come selezionare un modello di progettazione
8) Come utilizzare un modello di progettazione
9) coprono vari GoF modelli di progettazione con esempi - Mostra esempi di codice prima di applicare un modello di progettazione, e come appare dopo come Vince Huston fa nel suo examples.
10) Conclusione

Come già accennato, i modelli di progettazione sono davvero idee, quindi quando si insegna si deve trasmettere l'idea. Se capiscono il problema, la soluzione e le conseguenze del modello di progettazione, allora saranno molto meglio di provare a forzare gli schemi nel codice (e questo diventerà un incubo). Il riconoscimento di dove e quali modelli (se ce ne sono) possono essere applicati è il vero obiettivo. Gli esempi di Huston sono davvero buoni per mettere un esempio di codice alla classe e vedere se riescono a identificare un modello per migliorarlo. Spero che questo ti aiuti.

Answer 2

Head First Design Patterns sarebbe un ottimo punto di partenza. Copre i modelli di progettazione tradizionali.

Refactoring to Patterns potrebbe anche essere di interesse.

Se non è possibile acquistare un libro per ogni sviluppatore, acquistarne uno e distribuirlo.

Answer 3

I motivi sono difficili da imparare prima. Ho letto the GoF book così spesso allora. Ogni anno un altro schema mi affondava nella testa. Quindi il mio unico consiglio è che tu scelga un massimo di due modelli e trovi molti esempi su come risolverlo.

Un composito è qualcosa che tutti conoscono. Su questo puoi spiegare che potrebbe essere importante sapere che ha un nome che puoi usare e comunicare. Importante nei modelli è che rende facile per gli altri riconoscere le tue intenzioni. E questi piccoli nomi sono abbastanza utili.

Personalmente trovo il modello di metodo template davvero valido per lo sviluppo in OO. È così vicino a come dovrebbe accadere OOP che potrebbe avere il vantaggio di migliorare anche lo stile di codifica.

Answer 4

L'approccio adottato dalla maggior parte dei libri per spiegare i modelli è l'esatto contrario di ciò che mi piacerebbe vedere. Prendono uno schema, descrivono le precondizioni e cosa no e quindi ti danno un esempio. Preferirei piuttosto risolvere problemi concreti e discutere alternative. Quello che spicca, sarà il 'modello' - lo introdurrà come tale solo allora.

Scegliere i modelli che sono a) facili e b) molto probabilmente utilizzati nel codice. I singleton sono facili da imparare (dal momento che non coinvolgono soggetti/oggetti). Un altro interessante è il modello di osservatore.

Answer 5

Sei in una posizione unica per un insegnante: conosci gli sviluppatori e conosci il codice con cui stanno lavorando.

Un possibile approccio potrebbe essere quello di osservare una parte del codice spaventoso, e andare lungo le linee di "Come potremmo fare per migliorare questo? Come accade, c'è un modello di progettazione chiamato Observer ...."

Questo potrebbe finire per essere un mix di design patterns e refactoring. Ma potrebbe essere appropriato, dato che stai cercando di raggiungere gli sviluppatori che lavorano su una base di codice esistente.

Answer 6

Il problema con i modelli di apprendimento è che devi avere abbastanza esperienza con il software per aver visto il modello (normalmente senza nome) nel codice scritto o mantenuto. Se non hai mai scritto un osservatore, leggere la descrizione del modello non sarà facile da digerire.

Non sto dicendo che non si dovrebbe leggere sui modelli. Ma sappi che la capacità di apprezzare i modelli è limitata dall'inesperienza.

L'altro problema con gli schemi, e il problema che si avrà, è che non esistono. Almeno loro esistono ancora meno che il "software" esiste. I modelli sono idee e concetti. Non sono codice eseguibile. Il codice eseguibile può implementare un modello ma il contrario non esiste. Non puoi semplicemente digitare "singleton" nel tuo codice e improvvisamente esiste un singleton. Non esiste una lingua in cui l'aggiunta di un attributo "visitatore" faccia improvvisamente la colla per implementare il modello di visitatore. Esistono best practice ed esempi di pattern in varie lingue, ma non sono qualcosa che puoi inserire in una libreria e solo chiamare.

Quindi ciò che si vuole veramente è insegnare alcune buone pratiche in cui il nucleo di tali pratiche implica il riconoscimento e l'utilizzo di modelli. Essere osservanti è un'abilità molto difficile da insegnare (per tutte le forme di osservazione).

Il terzo problema con i pattern è che non sono realmente il dominio dei programmatori. Sono formalmente chiamati modelli di design per una ragione. Sono più propriamente una costruzione del tempo di progettazione. Certo, puoi usare i modelli per aiutare a rifattorizzare il codice esistente. Ma in generale, i modelli di progettazione sono in gergo per semplificare la discussione sul design. Questo è di nuovo il motivo per cui non ci sono librerie di codice singleton. Usare un singleton è un approccio al codice, non al codice stesso.

Tutto ciò che ha detto, cercando di educare i programmatori sui modelli di progettazione non può far male. Fare in modo che i programmatori pensino è una buona cosa e se solo uno di loro se ne allontana con più di una comprensione superficiale dei pattern, probabilmente esci dal gioco. In bocca al lupo.

Answer 7

Dai un'occhiata a questo sito: http://www.dofactory.com/Patterns/Patterns.aspx Si concentra sui molti tipi di modelli creativi, strutturali e comportamentali e fornisce esempi con il codice strutturale, reale e .net ottimizzato. Spero che questo aiuti

Answer 8

Ecco un tutorial da Nettuts +: A Beginner’s Guide to Design Patterns

molto facile da capire. Perfetto per iniziare modelli di design.

Questo tutorial spiega chiaramente:

• perché i modelli di progettazione sono importanti
• quando e perché dovrebbero essere utilizzati
• fornisce esempi, in PHP, per ogni modello

I seguenti schemi di progettazione sono illustrati nel tutorial:

• modello di strategia
• Adapter modello
• Factory Method modello
• Decorator pattern
• Singleton pattern