Limiti delle funzionalità nella programmazione funzionale

Question

Limiti delle funzionalità nella programmazione funzionale

#1 da (8 voti)

4

Mi piace molto il paradigma della programmazione funzionale, ma non sono ancora sicuro su come progettare un progetto di piccole / medie dimensioni con esso.

Quando uso OO, ho un insieme di entità etichettate (classi) con confini chiaramente definiti. Posso ragionare su cose come:

che cosa sta facendo questa classe?
dovrei inserire questo codice all'interno o al di fuori di una classe?
dovrei dividere questa classe in due?
in che modo un cliente vorrebbe utilizzare questa classe?

Quindi un grande vantaggio delle classi è che forniscono boundaries per un pezzo di funzionalità. Trovo che questo aiuti molto quando si progetta un'applicazione.

Nella programmazione funzionale, tutto sembra riguardare la composizione e l'astrazione di funzioni e strutture dati. Le classi di tipi in haskell sono principalmente lì per offrire il polimorfismo. Lo stesso vale per i prototipi in clojure.

Quando si progetta un'applicazione scritta in uno stile funzionale, qual è una buona "unità di funzionalità" su cui è possibile definire, etichettare e ragionare?

design functional-programming

posta Simon 02.05.2013 - 13:13

fonte

1 risposta

Leggi altre domande sui tag design functional-programming

Come posso migliorare questo design in modo che non sia necessario eseguire la scansione dinamica delle classi in fase di runtime? Mantenere il test e rilasciare i numeri di versione in sincronia

score 8 · Accepted Answer

In realtà, non deve essere così diverso.

È necessario identificare le strutture di base dei dati con cui lavorare. (Questo è ciò che le classi sono in OOP). Si scrivono funzioni che trattano vari aspetti di quella struttura dati e la raggruppano in un modulo o unità di compilazione.

Infine, usi le funzioni e i dati che hai in altre parti del tuo programma.

Ovviamente, le domande che stai facendo sembrano un po 'diverse in FP:

Che cosa sta facendo questa struttura dati? Niente, è solo Dato che tu (si spera) scrivi il codice nel modo più puro possibile, solo le parti minime del tuo codice sono in realtà facendo qualcosa.
Devo inserire questo codice all'interno o all'esterno della struttura dati? Questa è solo una domanda sintattica. In lingue come Haskell, non hai scelta: fuori.
Devo dividere questa lezione in due? Questa è una domanda difficile, ed è indipendente dal paradigma di programmazione. Eppure, in FP, tendi naturalmente a fare cose "dal basso verso l'alto", quindi inizi con dati facili, quasi banali e combinali in un modo più complesso.
Come vorrebbe un cliente usare questo? Attraverso le funzioni fornite (come OOP).