La letteratura di programmazione OO è piena di schemi progettuali. La maggior parte dei libri sulla programmazione orientata agli oggetti dedica un capitolo o due alla progettazione di modelli come fabbriche e decoratori. Quindi quali sono i modelli equivalenti nei linguaggi funzionali e perché nessuno ha ancora scritto un libro su di loro? C'è qualcosa di speciale nei linguaggi funzionali che ovvia alla necessità di schemi di progettazione?
OO e la programmazione funzionale sono due paradigmi di programmazione molto diversi, mentre i pattern di progettazione (DP) sono una parte significativa della progettazione e della programmazione di OO. DP non ha questo ruolo nella programmazione funzionale.
Si potrebbe persino dire che DP non è necessario nella programmazione funzionale - non esiste un prurito per cui DP è curabile.
Si potrebbe sostenere che gli schemi di progettazione sono un segno di funzionalità mancanti in un linguaggio di programmazione.
Peter Norvig ha trovato che 16 dei 23 modelli in Modelli di design i libri sono " invisibili o semplici r" in Lisp o Dylan.
"Molti pattern implicano uno stato di orientamento agli oggetti o più in generale mutevole, e quindi potrebbero non essere applicabili nei linguaggi di programmazione funzionale, in cui i dati sono immutabili o trattati come tali." - link
Jeremy Gibbons sta scrivendo il libro. Finché non è terminato, puoi leggere il suo blog, Modelli nella programmazione funzionale . Raccomanda di leggere i suoi post dal più vecchio al più recente.
Sfoglia anche le sue pubblicazioni . Copre i modelli Gang of Four in Progetta modelli come programmi generici di tipo datatype di ordine superiore e descrive gli schemi di programmazione con equazioni ricorsive in Programmazione Origami (si piega e si apre).
Il semplice fatto è che molti Pattern OO sarebbero considerati idiomi in linguaggi funzionali (specialmente i pattern GoF originali). Ad esempio il pattern Iterator (incorporato in linguaggi come C # ora) non è necessario in un Lisp o ML che ha operatori di sequenza.
Molti dei modelli che usiamo nei sistemi O-O ci aiutano ad eliminare i "non essenziali", così possiamo concentrarci sulla codifica degli oggetti. In altre parole, i pattern sono soluzioni alle parti non interessanti dell'applicazione. Dovremmo sfruttare i modelli per soddisfare i bisogni comuni che sono stati risolti prima (come i modelli di Fowlers Patterns di Enterprise Application Architecture per gestire cose come la trasmissione di database o xUnit Patterns per potenziare i test di unità) in modo che possiamo concentrarci sull'aggiunta di valore aziendale per l'applicazione.
Sono sicuro che al di là delle specificità dei pattern GoF, ci sono schemi di progettazione che saranno applicabili anche alla programmazione funzionale. Il fatto è che O-O è il paradigma dominante. Scrivere un libro di modelli che si rivolge a sviluppatori funzionali ... ma francamente non otterrà un semaforo verde da un editore. Ecco cosa si riduce a. Non c'è abbastanza mercato per i Modelli Funzionali per avere un numero significativo di libri dedicati all'argomento.
Un bel discorso (~ 45 min) su questo argomento di Stuart Sierra:
Non necessariamente vincolante e autorevole, ma ho riconosciuto alcuni dei suoi esempi dalla mia esperienza con l'uso di FP per l'analisi dei dati.
Esempi scritti in Clojure, ma probabilmente applicabili a qualsiasi linguaggio FP. I nomi che dà agli schemi che copre sono:
Se sei sinceramente interessato ad apprendere gli schemi di progettazione non guardare oltre Haskell. Se prendi il tempo per impara la lingua nel modo più duro ti imbatterai in e sii accogliente con la maggior parte dei modelli fondamentali: sono cotti nella lingua.
Non saltare le monadi. Ci sono un sacco di spiegazioni prolisse là fuori e ci vuole un po 'di lavoro per far affondare le idee, ma se continui a tapparti, alla fine ti verrà in mente e rimarrai sorpreso da quanti motivi di design possono essere costruisci sopra questa astrazione / interfaccia.
Una volta che hai inghiottito Haskell, avrai abbastanza dell'arsenale FP a tua disposizione per essere pericoloso. Il punto è, tienilo finché non lo ottieni. Non ci sono scorciatoie.
Nella misura in cui la metodologia di progettazione per FP è progettare i tuoi tipi per riflettere accuratamente lo spazio del problema e l'implementazione dovrebbe seguire automaticamente, l'equivalente FP di un libro su modelli di progettazione è qualcosa come Chris
Strutture dati funzionali prettamente .Leggi altre domande sui tag design-patterns functional-programming books
