Voglio spiegare i modelli di progettazione a mia nipote, ma faccio sempre fatica a farlo. È in gran parte dovuto alla mia mancanza di una chiara comprensione dei modelli di progettazione. Come suggerisci di spiegare pattern come MVC, Singleton, Factory, Repository ecc in termini così semplici che anche i bambini di 10 anni possono capire.
Sto cercando esempi che possano facilitare la comprensione dei pattern. Esempi con giocattoli, film, musica ecc.
Penso che l'inizio del articolo di Wikipedia sia probabilmente un buon inizio:
A design pattern is a general reusable solution to a commonly occurring problem.
O vuoi spiegare le specifiche di quei particolari modelli?
Dipende dal motivo per cui vuoi spiegarlo. Se vuoi solo spiegare l'idea dei pattern, attingerei esempi dall'architettura in A Pattern Language. Questi ricercatori hanno scoperto che certi aspetti di un edificio o di una stanza facevano sì che alla gente piacesse vivere o lavorare in quell'edificio o stanza - in tutto il mondo in culture diverse, con materiali da costruzione diversi e in diversi tipi di quartieri. Ad esempio "Luce su due lati". Le stanze con finestre su due pareti sono molto più belle di quelle con solo una (o nessuna). Anche nel software ci sono modelli del genere - anche usando diversi linguaggi di programmazione, alcuni schemi si ripetono. E anche in software molto diversi: un gioco, qualcosa per i calcoli finanziari, il motore all'interno di Facebook e così via.
Quindi, se vuoi parlare di un particolare modello (non sai bene perché, a un bambino di dieci anni) potresti iniziare dando esempi di dove è stato usato prima di provare a spiegare come funziona. Così Composite ti consente di evitare la ricorsione esplicita quando stai calcolando il peso di una valigia sommando il peso del contenitore e il totale di tutti i contenitori e le cose che contiene, ma funziona anche per calcolare il carico salariale in una società o capacità in un complesso di produzione. Se questo è anche un po 'interessante per i dieci anni, potresti provare a spiegare come funziona.
Esistono modelli di progettazione perché alcune persone hanno capito che c'erano dei modi per far funzionare bene i bit del software e volevano condividere le loro intuizioni.
Puoi pensare ai modelli di design nello stesso modo in cui pensi a gruppi di persone. Ad esempio, a volte abbiamo una persona che facilita tutti i nostri incontri. È come un pattern Controller, che facilita le interazioni tra gli oggetti.
Oppure immagina un pubblico, in cui qualcuno nella parte anteriore della stanza osserva che la gente alza le mani, quindi ripete la domanda in modo che tutti possano sentire, o forse reagisce rispondendo. Sarebbe simile a un modello soggetto / osservatore.
Ci sono schemi che si comportano come traduttori (il modello dell'adattatore), come guardie di sicurezza (il proxy), come esperti in un campo (Singletons), o come le persone che controllano che la tua auto funzioni (validatori).
La differenza tra oggetti e persone è che possiamo praticamente creare tanti oggetti quanti ne vogliamo e avere più copie di essi. Ciò rende importante capire quali responsabilità dovrebbero avere gli oggetti, mantenere le loro responsabilità di piccole dimensioni e cercare di non duplicare ciò che fanno, in modo che il software non diventi troppo complicato. Gli esperti hanno una grande esperienza in questo, e ci hanno dato questi modelli di come il software efficace interagisce in modo che possiamo decidere quale tipo di ruolo è la migliore metafora per il lavoro che stiamo cercando di fare, e ottenere il pezzi di software per collaborare nel modo più appropriato.
Dille che sono abituati a costruire singoli componenti di un sistema, come le tecniche di cottura utilizzate per costruire un pasto / piatto. Immagina di preparare la cena, con patate, carne e verdure. Decidi tu vuoi le patate bollite e schiacciate, la carne alla griglia e le verdure al vapore. Usi il modello di disegno della griglia per cuocere la carne, i bollori e i modelli di poltiglia per le patate e il modello di vapore per la verdura.
La maggior parte di questi modelli di progettazione fa parte del design orientato agli oggetti. Non puoi davvero spiegarlo a qualcuno senza alcuna comprensione dell'OOD. Potresti descrivere l'obiettivo che raggiungi con un dato schema, ma non come funziona, né perché ne hai bisogno. A meno che, naturalmente, non entri nella spiegazione dell'intero OOD.
I design pattern sono stati descritti per la prima volta per l'architettura. Cose come la posizione della piazza, edifici e altri layout generalmente ripetuti. Potresti iniziare da lì. Cose come l'ingresso principale si affacciano sulla strada, la porta verso l'angolo della stanza e qualsiasi altra cosa tu possa pensare. Gli schemi dell'autore originale non erano ampiamente usati. Si dice che ora affermi che i modelli stessi non sono abbastanza.
Parla degli oggetti in movimento nella stanza. Metti una sedia davanti alla porta. Avrebbe senso spostare le finestre o la porta altrove. Perché o perché no?
Prova qualcosa come ambientare un posto al tavolo. Prova a organizzare le cose per dimensione allontanandoti da te. Non è il modello normale e difficile da lavorare. Configuralo normalmente. Si tratta di un layout adatto per un bicchiere di succo? I pattern non sono sempre appropriati.
Viviamo con i modelli tutto il tempo. Prendi tre o quattro libri e inizia a sfogliarli. C'è un modello ovvio nel layout; frontespizio, sommario, contenuto e indice. Non tutti i componenti sono obbligatori, ma sarebbe un po 'confuso vederli fuori posto.
I modelli di progettazione sono per lo sviluppo del software quali sono le maschere per la lavorazione del legno. È uno strumento con cui puoi realizzare "tagli" ben noti da utilizzare in progetti più grandi.
Nota che non hai bisogno del jig per fare il taglio, è solo più facile in alcune circostanze.
Sento che la mia altra risposta sta per il caso generale, ma l'OP ha commentato chiedendo dei dettagli (quindi ho ritenuto che meritasse una risposta separata). Purtroppo non ho familiarità con il modello del repository, ma prenderò una pugnalata agli altri. Di norma, penso che il modo migliore per spiegarli sia attraverso quale problema si vuole risolvere, perché lo si vuole risolvere e come il problema lo porta a termine.
Questo schema è usato quando vogliamo garantire che ce ne sia solo uno. Il modello si ottiene impedendo ad altri di creare il nostro oggetto.
Questo modello è usato per mantenere le cose modulari con tutti i vantaggi che ne derivano. La vista è l '"interfaccia utente", il modello è i dati (inclusa la logica aziendale) e il controller è il modo in cui le azioni dell'utente manipolano il modello. Con questa modularità, nulla mi impedisce di avere più viste / controller per lavorare con lo stesso modello. Per un esempio troppo semplificato, posso interagire con la mia email ("modello") attraverso un sito Web, un'applicazione desktop e il mio iPhone ("viste + controller"). Se ho una casella postale di gruppo condivisa, potrei creare un controller che non invii email e riutilizzare la stessa vista applicativa ed e-mail. (sì, troppo semplicistico, ma si spera comprensibile :))
Inoltre, con questa separazione ben definita dei problemi, i cambiamenti in uno (idealmente) non richiedono modifiche in un altro. Esempio concreto, se ho bisogno di supportare la lettura / scrittura su un database MySQL invece che su un database Oracle, ho solo bisogno di cambiare il mio modello, e la mia vista / controller non cambia.
Devi stare attento qui dato che ci sono molti modelli simili chiamati Factory ... Parlerò della Fabbrica astratta , ma dovresti sapere che esiste anche un modello Metodo di fabbrica .
Fondamentalmente, vorrei utilizzare una Fabbrica astratta quando so quali passi voglio eseguire, ma i passaggi su come eseguire questi passaggi individuali potrebbero variare. Ad esempio, potrei creare un'applicazione in cui è necessario creare una finestra di dialogo con un pulsante. Avendo il mio codice utilizzare un'ipotetica interfaccia utente, se ho bisogno del mio codice su Mac o Linux anziché su Windows, fornisco semplicemente un factory diverso e il resto del mio codice non cambia. Per un esempio potenzialmente più selvaggio, potrei avere una Web Factory e improvvisamente la maggior parte del codice che supporta la mia applicazione desktop sta ora alimentando anche un sito Web ricco :) (ok, non pratico per altri motivi, ma in teoria :))
A un bambino di 10 anni che vuole essere un hacker - direi.
Immagina se potessi avere alcuni dei migliori hacker del mondo seduti accanto a te quando stavi tagliando via .. e ogni tanto direbbero ... "sai se lo fai in questo modo ... [ insert pattern] ... allora il codice sarà [più veloce / più sicuro / più mantenibile / ecc.] "quanto sarebbe bello.
Ora presumo che lei sia entusiasta dell'idea - non sprecherei il mio tempo a spiegare ogni schema che avrei impostato per il suo "compito di hacking" .. e poi post applicare un modello di progettazione e spiegare il valore ... quindi basta lei ad alcune buone risorse e vedere dove va.
Ma per lo più lei avrà bisogno di apprenderli tramite il tutoraggio.
Leggi altre domande sui tag design-patterns