Pensiero architettonico in lingue funzionali

Question

La casella Le mie domande correlate si sovrappone a domande di programmazione funzionale. Dopo aver esaminato le più rilevanti, sono comunque curioso di sentire opinioni su quanto segue:

Come pensi di strutturare un'applicazione in un linguaggio funzionale?

Non sto parlando di una grammatica specifica della lingua. Sono interessato ai paradigmi organizzativi concettuali (ad esempio l'orientamento agli oggetti).

Come molti, la mia prima esposizione all'incapsulamento e al riutilizzo del codice proveniva dallo sfondo di OO. Poiché ho svolto ricerche su linguaggi diversi, la programmazione funzionale ha catturato la mia attenzione. Sto iniziando a cogliere i vantaggi dell'immutabilità, delle funzioni di ordine superiore, eccetera. Ma continuo a perdere il senso di come strutturare un'applicazione funzionale senza ricorrere ai concetti di OO. In realtà, molti degli esempi funzionali che ho visto hanno più in comune con il codice spaghetti, anche se sono sicuro che ciò è dovuto alla semplicità degli esempi piuttosto che a un difetto intrinseco nell'approccio funzionale.

Questa domanda è familiare a "quando dovrei usare la programmazione funzionale", ma mi sono già accontentato del fatto che l'approccio funzionale, nonostante i pro e i contro in alcuni domini, sia utilizzabile per qualsiasi cosa tu voglia. Ho solo difficoltà a immaginare l'organizzazione di grandi dimensioni di un'app complessa.

Answer 1

La maggior parte dei modelli di progettazione complessivi sono completamente applicabili:

separazione degli interessi; Model-Control-Presentation (in tutte le sue varianti); Architettura stratificata; Input-Process-Output, ecc.

Una volta che si è decomposto un grosso problema in problemi più piccoli, i problemi minori sono una questione di lavoro attraverso le varie trasformazioni dalla rappresentazione di origine a quella di destinazione.

trovo che il input-processo-output modello e trasformazione gasdotto schemi di aiuto.

Answer 2

Alla fine degli anni '70, Barbara Liskov e altri hanno sviluppato un'imbarcazione di tecniche di "progettazione orientata agli oggetti" su larga scala che sono ancora ampiamente utilizzate oggi e che si applicano immutate alla programmazione funzionale. Sono più facili da applicare con un linguaggio che ha interfacce e implementazioni esplicite, il che significa Standard ML (dove le interfacce sono chiamate "firme" e le implementazioni sono chiamate "strutture" o "functors") o Objective Caml (dove le interfacce sono chiamate "tipi di modulo") "e le implementazioni sono chiamate" moduli "). Se si preferisce Scheme, il linguaggio "unitario" sviluppato da Matthew Flatt e Matthias Felleisen è incorporato in PLT Scheme ed è un ottimo modo per esprimere funzioni su larga scala.

In breve:

• organizzare le applicazioni in tutto tipi astratti (classi in OO, "tipi astratti" in FP) e le operazioni su tali tipi.

• Utilizzare i meccanismi di incapsulamento (classi in OO, moduli in FP) per nascondere le rappresentazioni dei tipi di astratti.

• Struttura dell'applicazione in modo che ogni implementazione dipenda indirettamente da altre implementazioni, attraverso le loro interfacce. In questo modo limiti la quantità di codice che devi capire per costruire o modificare qualsiasi pezzo della tua applicazione.

• Vai in città!

La differenza principale è che quando si scrivono programmi funzionali, non si utilizza l'ereditarietà per riutilizzare le implementazioni. Invece si utilizzano le funzioni di ordine superiore o si utilizza modules which take other modules as parameters.

Sommario: a livello di architettura, non c'è molta differenza, ma quando si utilizzano i linguaggi funzionali potrebbe essere necessario cercare un po 'più difficile per trovare i meccanismi di incapsulamento di cui si ha bisogno.