Dove sono tutti i modelli di progettazione di programmazione funzionale? [chiuso]

La letteratura sulla programmazione OO è piena di modelli di progettazione. 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 gli schemi equivalenti nei linguaggi funzionali e perché nessuno ha ancora scritto un libro su di essi? C'è qualcosa di speciale nei linguaggi funzionali che ovvia alla necessità di modelli di progettazione?

OO e programmazione funzionale sono due paradigmi di programmazione molto diversi e i modelli di progettazione (DP) sono una parte significativa della progettazione e della programmazione di OO. DP non ha tale ruolo nella programmazione funzionale.

Si potrebbe anche dire che DP non è necessario nella programmazione funzionale - non esiste prurito per cui DP è una cura.

• Si potrebbe sostenere che i modelli di progettazione sono un segno di caratteristiche mancanti in un linguaggio di programmazione.

• Peter Norvig ha scoperto che 16 dei 23 pattern nel libro Design Patterns sono " invisibili o semplici " in Lisp o Dylan.

• "Molti modelli implicano l'orientamento agli oggetti o lo stato più generalmente mutabile, e quindi potrebbero non essere applicabili nei linguaggi di programmazione funzionale, in cui i dati sono immutabili o trattati come tali." - http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29

Jeremy Gibbons sta scrivendo il libro. Finché non è finito, puoi leggere il suo blog, Patterns in Functional Programming . Si consiglia di leggere i suoi post dal più vecchio al più recente.

Sfoglia anche le sue pubblicazioni . Copre Gang of Four pattern in Design Patterns come Programmi generici di dati di ordine superiore e descrive i modelli di programmazione con equazioni ricorsive nella Programmazione Origami (pieghe e spiegazioni).

Il semplice fatto è che molti Pattern OO sarebbero considerati Idiomi in linguaggi funzionali (specialmente i pattern GoF originali). Ad esempio, il modello Iterator (integrato in linguaggi come C # ora) non è necessario in un Lisp o ML con operatori di sequenza.

Molti dei modelli che utilizziamo nei sistemi OO sono lì per aiutarci a rimuovere i "non essenziali" in modo che possiamo concentrarci su oggetti di codifica. In altre parole, i modelli sono soluzioni per le parti non interessanti dell'applicazione. Dovremmo sfruttare i modelli per soddisfare le esigenze comuni che sono state risolte in precedenza (come i modelli in Fowlers Patterns of Enterprise Application Architecture per gestire cose come la trasmissione di database o xUnit Patterns per migliorare i test delle unità) in modo da poterci concentrare sull'aggiunta di valore aziendale per l'applicazione.

Sono sicuro che oltre alle specifiche dei modelli GoF, ci sono modelli di progettazione che saranno applicabili anche alla programmazione funzionale. Il fatto è che OO è il paradigma dominante. Scrivere un libro di schemi che si rivolge agli sviluppatori funzionali ... francamente non otterrà il via libera da un editore. Questo è ciò a cui si riduce. Non c'è abbastanza mercato per i Functional Patterns per avere un numero significativo di libri dedicati all'argomento.

Una bella chiacchierata (~ 45 min) su questo argomento di Stuart Sierra:

http://www.infoq.com/presentations/Clojure-Design-Patterns

Non necessariamente vincolante e autorevole, ma ho riconosciuto alcuni dei suoi esempi dalla mia esperienza con 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:

• Stato / Evento
• conseguenze
• Accumulatore
• Ridurre / Combina
• Espansione ricorsiva
• conduttura
• involucro
• Gettone
• Osservatore
• Strategia

Se sei veramente interessato all'apprendimento dei modelli di design, non cercare oltre Haskell. Se ti prendi il tempo per imparare la lingua nel modo più difficile in cui ti imbatti e ti senti più a tuo agio con la maggior parte dei modelli di base, sono integrati nella lingua.

Non saltare le monadi. Ci sono un sacco di spiegazioni prolissi là fuori e ci vuole un po 'per far affondare le idee, ma se continui a collegarti, alla fine ti sorgerà e rimarrai stupito da quanti modelli di design possono essere basarsi su questa unica astrazione / interfaccia.

Una volta che grugnisci Haskell, avrai abbastanza dell'arsenale FP a tua disposizione per essere pericoloso. Il punto è, continua fino a quando non lo ottieni. Non ci sono scorciatoie.

Nella misura in cui la metodologia di progettazione per FP è quella di progettare i tuoi tipi per riflettere accuratamente lo spazio del problema e l'implementazione dovrebbe seguire automaticamente, l'equivalente FP di un libro sui modelli di progettazione è qualcosa come le Strutture di dati puramente funzionali di Chris Okasaki .