Di recente ho letto un libro intitolato Programmazione funzionale in C # e mi viene in mente che la natura immutabile e apolide della programmazione funzionale realizza risultati simili ai modelli di iniezione di dipendenza ed è forse anche un approccio migliore, soprattutto per quanto riguarda i test unitari.

Sarei grato se qualcuno che avesse esperienza con entrambi gli approcci potesse condividere i propri pensieri ed esperienze per rispondere alla domanda principale: la Programmazione Funzionale è una valida alternativa ai modelli di iniezione di dipendenza?

La gestione delle dipendenze è un grosso problema in OOP per i seguenti due motivi:

• Lo stretto accoppiamento di dati e codice.
• Uso ubiquitario di effetti collaterali.

La maggior parte dei programmatori OO ritiene che lo stretto accoppiamento di dati e codice sia del tutto vantaggioso, ma comporta un costo. La gestione del flusso di dati attraverso i livelli è una parte inevitabile della programmazione in qualsiasi paradigma. L'accoppiamento di dati e codice aggiunge l'ulteriore problema che se si desidera utilizzare una funzione in un determinato punto, è necessario trovare un modo per portare il suo oggetto a quel punto.

L'uso di effetti collaterali crea difficoltà simili. Se usi un effetto collaterale per alcune funzionalità, ma vuoi essere in grado di scambiarne l'implementazione, praticamente non hai altra scelta che iniettare quella dipendenza.

Consideriamo ad esempio un programma di spammer che raschia le pagine Web per gli indirizzi e-mail, quindi le invia per e-mail. Se hai una mentalità DI, in questo momento stai pensando ai servizi che incapsulerai dietro le interfacce e quali servizi verranno iniettati dove. Lascerò quel disegno come esercizio per il lettore. Se hai una mentalità FP, in questo momento stai pensando agli ingressi e alle uscite per il livello più basso di funzioni, come:

• Immettere un indirizzo per la pagina Web, generare il testo di quella pagina.
• Inserisci il testo di una pagina, genera un elenco di collegamenti da quella pagina.
• Inserisci il testo di una pagina, visualizza un elenco di indirizzi e-mail su quella pagina.
• Inserisci un elenco di indirizzi e-mail, genera un elenco di indirizzi e-mail con i duplicati rimossi.
• Inserisci un indirizzo e-mail, invia un'e-mail di spam per quell'indirizzo.
• Inserisci un'email di spam, invia i comandi SMTP per inviare l'e-mail.

Quando si pensa in termini di input e output, non ci sono dipendenze di funzioni, ma solo dipendenze di dati. Questo è ciò che li rende così facili da testare l'unità. Il tuo livello successivo organizza l'output di una funzione da inserire nell'input del successivo e può facilmente sostituire le varie implementazioni secondo necessità.

In un senso molto reale, la programmazione funzionale ti spinge naturalmente a invertire sempre le dipendenze delle tue funzioni, e quindi di solito non devi prendere alcuna misura speciale per farlo dopo il fatto. Quando lo fai, strumenti come le funzioni di ordine superiore, le chiusure e l'applicazione parziale rendono più facile eseguire con meno boilerplate.

Si noti che non sono le dipendenze stesse ad essere problematiche. Sono le dipendenze che indicano la direzione sbagliata. Il livello successivo può avere una funzione come:

processText = spamToSMTP . emailAddressToSpam . removeEmailDups . textToEmailAddresses

Va perfettamente bene che questo livello abbia dipendenze codificate in questo modo, perché il suo unico scopo è incollare insieme le funzioni del livello inferiore. Scambiare un'implementazione è semplice come creare una composizione diversa:

processTextFancy = spamToSMTP . emailAddressToFancySpam . removeEmailDups . textToEmailAddresses

Questa facile ricomposizione è resa possibile dalla mancanza di effetti collaterali. Le funzioni del livello inferiore sono completamente indipendenti l'una dall'altra. Il livello successivo può scegliere quale processTextviene effettivamente utilizzato in base a una configurazione utente:

actuallyUsedProcessText = if (config == "Fancy") then processTextFancy else processText

Ancora una volta, non è un problema perché tutte le dipendenze indicano un modo. Non è necessario invertire alcune dipendenze per farle puntare tutte allo stesso modo, perché le funzioni pure ci hanno già costretto a farlo.

Nota che potresti renderlo molto più accoppiato passando configal livello più basso invece di controllarlo in alto. FP non ti impedisce di farlo, ma tende a renderlo molto più fastidioso se ci provi.

la Programmazione funzionale è una valida alternativa ai modelli di iniezione di dipendenza?

Questo mi sembra una domanda strana. Gli approcci di programmazione funzionale sono in gran parte tangenziali all'iniezione di dipendenza.

Certo, avere uno stato immutabile può spingerti a non "imbrogliare" avendo effetti collaterali o usando lo stato di classe come un contratto implicito tra le funzioni. Rende più esplicito il passaggio di dati, che suppongo sia la forma più elementare di iniezione di dipendenza. E il concetto di programmazione funzionale del passaggio di funzioni rende tutto molto più semplice.

Ma non rimuove le dipendenze. Le tue operazioni necessitano ancora di tutti i dati / operazioni di cui avevano bisogno quando il tuo stato era mutabile. E hai ancora bisogno di ottenere quelle dipendenze lì in qualche modo. Quindi non direi che gli approcci di programmazione funzionale sostituiscono il DI, quindi non esistono alternative.

Semmai, ti hanno appena mostrato quanto un cattivo codice OO possa creare dipendenze implicite di cui i programmatori raramente pensano.

La rapida risposta alla tua domanda è: No .

Ma come altri hanno affermato, la domanda sposa due concetti, in qualche modo non correlati.

Facciamo questo passo per passo.

DI risulta in uno stile non funzionale

Nel cuore della programmazione delle funzioni ci sono funzioni pure: funzioni che mappano l'input sull'output, in modo da ottenere sempre lo stesso output per un determinato input.

DI generalmente indica che l'unità non è più pura poiché l'output può variare a seconda dell'iniezione. Ad esempio, nella seguente funzione:

const bookSeats = ( seatCount, getBookedSeatCount ) => { ... }

getBookedSeatCount(una funzione) può variare producendo risultati diversi per lo stesso input dato. Questo rende anche bookSeatsimpuro.

Ci sono eccezioni per questo: è possibile iniettare uno dei due algoritmi di ordinamento che implementano la stessa mappatura input-output, sebbene usando algoritmi diversi. Ma queste sono eccezioni.

Un sistema non può essere puro

Il fatto che un sistema non possa essere puro è ugualmente ignorato come è affermato nelle fonti di programmazione funzionale.

Un sistema deve avere effetti collaterali con esempi ovvi che sono:

• UI
• Banca dati
• API (nell'architettura client-server)

Quindi parte del tuo sistema deve comportare effetti collaterali e quella parte può anche coinvolgere uno stile imperativo o uno stile OO.

Il paradigma shell-core

Prendendo in prestito i termini del superbo discorso di Gary Bernhardt sui confini , una buona architettura di sistema (o modulo) includerà questi due livelli:

• Nucleo
  • Funzioni pure
  • branching
  • Nessuna dipendenza
• Conchiglia
  • Impure (effetti collaterali)
  • Nessuna ramificazione
  • dipendenze
  • Può essere imperativo, coinvolgere lo stile OO, ecc.

La chiave da asporto è "dividere" il sistema nella sua parte pura (il nucleo) e nella parte impura (il guscio).

Sebbene offra una soluzione (e una conclusione) leggermente imperfetta, questo articolo di Mark Seemann propone lo stesso concetto. L'implementazione di Haskell è particolarmente approfondita in quanto mostra che tutto può essere fatto usando FP.

DI e FP

L'impiego di DI è perfettamente ragionevole anche se la maggior parte dell'applicazione è pura. La chiave è confinare il DI all'interno della shell impura.

Un esempio saranno gli stub API: vuoi la vera API in produzione, ma usa gli stub nei test. L'adesione al modello shell-core aiuterà molto qui.

Conclusione

Quindi FP e DI non sono esattamente alternative. Probabilmente avrai entrambi nel tuo sistema e il consiglio è di assicurare la separazione tra la parte pura e impura del sistema, dove FP e DI risiedono rispettivamente.

Dal punto di vista OOP le funzioni possono essere considerate come interfacce a metodo singolo.

L'interfaccia è un contratto più forte di una funzione.

Se stai usando un approccio funzionale e fai molti DI, rispetto all'utilizzo di un approccio OOP otterrai più candidati per ogni dipendenza.

void DoStuff(Func<DateTime> getDateTime) {}; //Anything that satisfies the signature can be injected.

vs

void DoStuff(IDateTimeProvider dateTimeProvider) {}; //Only types implementing the interface can be injected.