Programmazione funzionale vs programmazione orientata agli oggetti [chiuso]

Finora sono stato principalmente esposto alla programmazione OO e non vedo l'ora di imparare un linguaggio funzionale. Le mie domande sono:

• Quando scegli la programmazione funzionale piuttosto che orientata agli oggetti?
• Quali sono le definizioni tipiche dei problemi in cui la programmazione funzionale è una scelta migliore?

Quando scegli la programmazione funzionale piuttosto che orientata agli oggetti?

Quando prevedi un diverso tipo di evoluzione del software:

• I linguaggi orientati agli oggetti sono utili quando hai un set fisso di operazioni sulle cose e man mano che il tuo codice si evolve, aggiungi principalmente nuove cose. Ciò può essere ottenuto aggiungendo nuove classi che implementano metodi esistenti e le classi esistenti vengono lasciate sole.

• I linguaggi funzionali sono buoni quando hai un set fisso di cose e man mano che il tuo codice si evolve, aggiungi principalmente nuove operazioni su cose esistenti. Ciò può essere ottenuto aggiungendo nuove funzioni che calcolano con tipi di dati esistenti e le funzioni esistenti vengono lasciate sole.

Quando l'evoluzione va nella direzione sbagliata, hai problemi:

• L'aggiunta di una nuova operazione a un programma orientato agli oggetti potrebbe richiedere la modifica di molte definizioni di classe per aggiungere un nuovo metodo.

• L'aggiunta di un nuovo tipo di cose a un programma funzionale potrebbe richiedere la modifica di molte definizioni di funzioni per aggiungere un nuovo caso.

Questo problema è noto da molti anni; nel 1998, Phil Wadler lo ha definito il "problema dell'espressione" . Sebbene alcuni ricercatori ritengano che il problema dell'espressione possa essere affrontato con funzionalità linguistiche come i mixin, una soluzione ampiamente accettata deve ancora raggiungere il mainstream.

Quali sono le definizioni tipiche dei problemi in cui la programmazione funzionale è una scelta migliore?

I linguaggi funzionali eccellono nel manipolare i dati simbolici in forma di albero. Un esempio preferito sono i compilatori, in cui le lingue di origine e intermedie cambiano di rado (principalmente le stesse cose ), ma gli autori di compilatori aggiungono sempre nuove traduzioni e miglioramenti o ottimizzazioni del codice (nuove operazioni sulle cose). Compilazione e traduzione più in generale sono "app killer" per linguaggi funzionali.

Non devi necessariamente scegliere tra i due paradigmi. È possibile scrivere software con un'architettura OO utilizzando molti concetti funzionali. FP e OOP sono di natura ortogonale .

Prendiamo ad esempio C #. Si potrebbe dire che è principalmente OOP, ma ci sono molti concetti e costrutti FP. Se consideri Linq , i costrutti più importanti che consentono a Linq di esistere sono di natura funzionale: espressioni lambda .

Un altro esempio, F #. Si potrebbe dire che è principalmente FP, ma ci sono molti concetti e costrutti OOP disponibili. Puoi definire classi, classi astratte, interfacce, gestire l'ereditarietà. Puoi persino usare la mutabilità quando rende il codice più chiaro o quando aumenta notevolmente le prestazioni.

Molte lingue moderne sono multi-paradigma.

Letture consigliate

Dato che sono nella stessa barca (sfondo OOP, apprendimento FP), ti suggerirei alcune letture che ho davvero apprezzato:

• Programmazione funzionale per lo sviluppo quotidiano di .NET , di Jeremy Miller. Un grande articolo (sebbene mal formattato) che mostra molte tecniche ed esempi pratici e reali di FP su C #.

• Programmazione funzionale nel mondo reale , di Tomas Petricek. Un grande libro che tratta principalmente i concetti di FP, cercando di spiegare cosa sono, quando dovrebbero essere usati. Ci sono molti esempi sia in F # che in C #. Inoltre, il blog di Petricek è un'ottima fonte di informazioni.

La programmazione orientata agli oggetti offre:

1. Incapsulamento, a
   • controllare la mutazione dello stato interno
   • limitare l'accoppiamento alla rappresentazione interna
2. Sottotipizzazione, che consente:
   • sostituzione di tipi compatibili (polimorfismo)
   • un mezzo grezzo per condividere l'implementazione tra le classi (ereditarietà dell'implementazione)

La programmazione funzionale, in Haskell o persino in Scala, può consentire la sostituzione attraverso un meccanismo più generale di classi di tipi. Lo stato interno mutevole è scoraggiato o proibito. L'incapsulamento della rappresentazione interna può anche essere raggiunto. Vedi Haskell vs OOP per un buon confronto.

L'affermazione di Norman secondo cui "L'aggiunta di un nuovo tipo di cose a un programma funzionale può richiedere la modifica di molte definizioni di funzioni per aggiungere un nuovo caso". dipende da quanto bene il codice funzionale ha impiegato classi di tipi. Se la corrispondenza dei modelli su un particolare tipo di dati astratti è diffusa in una base di codice, si risentirà effettivamente di questo problema, ma forse è un progetto scadente per cominciare.

EDITED Rimosso il riferimento alle conversioni implicite quando si discutono le classi di tipi. In Scala, le classi di tipi sono codificate con parametri impliciti, non conversioni, sebbene le conversioni implicite siano un altro modo per ottenere la sostituzione di tipi compatibili.

1. Se ti trovi in ​​un ambiente fortemente concorrenziale, è utile la pura programmazione funzionale. La mancanza di uno stato mutevole rende la concorrenza quasi banale. Vedi Erlang.

2. In un linguaggio multiparadigm, potresti voler modellare alcune cose funzionalmente se l'esistenza di uno stato mutabile è un dettaglio di implementazione, e quindi FP è un buon modello per il dominio problematico. Ad esempio, vedi la comprensione delle liste in Python o std.range nel linguaggio di programmazione D. Questi sono ispirati dalla programmazione funzionale.