Equivalente dei principi SOLID per la programmazione funzionale

Ho trovato i principi SOLID abbastanza utili quando si pensa al design orientato agli oggetti.

Esiste un insieme simile / equivalente di principi indipendenti dalla lingua su misura per la programmazione funzionale?

design-patterns functional-programming solid

— mikera
fonte

FWIW, questo è stato discusso brevemente su SO un anno fa

— StuartLC

DI e HOF: programmers.stackexchange.com/questions/103508/…

— paul

Questo video e queste diapositive presentano i principi SOLID applicati alla programmazione funzionale. Entrambi usano il linguaggio Clojure come esempio, ma i principi valgono in altre lingue.

— mascip,

slideshare.net/RichardWarburton/…

— Ray Tayek,

vedi anche: La programmazione funzionale è un superset di oggetti orientati?

— moscerino

Risposte:

È un po 'difficile trovare equivalenti ma posso provare:

S (SRP) in FP una funzione crea SEMPRE lo stesso output per gli stessi argomenti, questo è chiamato trasparenza referenziale
O (OCP) in FP esiste un concetto chiamato tipi di dati algebrici, dai un'occhiata a come si relaziona con le gerarchie di classi e quale problema entrambi cercano di risolvere ¹
L (LSP) Il principio di sostituzione di Liskov è Contravarianza ²
D (DIP) nella programmazione funzionale generale raggiunge l'astrazione attraverso la composizione della funzione, ci sono anche altri meccanismi con l'aiuto della teoria delle categorie (ad esempio monoide o functor), per "Iniezione delle dipendenze" ³

— AndreasScheinert
fonte

Sto ancora pensando a come sei passato dal principio della responsabilità singola alla trasparenza referenziale . Quei due sono indipendenti. SRP riguarda una funzione che ha un unico scopo. Può essere o meno trasparente dal punto di vista referenziale al riguardo.

— Goran Jovic,

Ah, mio male - lo capisco ora. Questi sono equivalenti nel senso di essere principi e formare lo stesso acronimo, non nel senso di significare la stessa cosa o qualcosa di simile. Ci scusiamo per il downvote!

— Goran Jovic,

Esatto, questo è il modo previsto per leggerlo. Ho provato a descrivere una mappatura per quei termini nel contesto di fp.

— AndreasScheinert,

Amico che non puoi modificare un commento, in effetti le cose DOVREBBERO significare almeno qualcosa di simile.

— AndreasScheinert,

Forse le funzioni di ordine superiore possono fornire un tipo di iniezione di dipendenza: si inietta una funzione concreta come parametro in una funzione generica (di ordine superiore).

— Giorgio,

SOLID risulta essere una buona idea anche per i regni funzionale / imperativo.

SRP : "Solo una cosa" è stata presa in primo luogo dalla programmazione imperativa. Avere funzioni piccole e mirate è buono.

OCP - Permettere di cambiare comportamento senza modificare il codice è buono. La programmazione funzionale utilizza funzioni di ordine superiore più dell'ereditarietà, ma il principio vale.

LSP - Rispettare alcuni contratti di interfaccia è altrettanto utile nella programmazione funzionale quanto nell'orientamento agli oggetti. Se una funzione di ordinamento accetta un comparatore, allora ci si aspetterebbe che il comportamento "0 sia uguale a, inferiore a fornisce risultati negativi, maggiore di risultati positivi".

ISP - La maggior parte dei linguaggi funzionali ha ancora delle strutture. Specificare il set di dati più piccolo richiesto da una funzione è ancora una buona pratica. Richiedere l'interfaccia meno specifica per i dati (perché usare Elenchi di ints quando funzionano anche le enumerazioni di T?) È ancora una buona pratica.

DIP - Specificare i parametri per una funzione (o una funzione di ordine superiore per recuperarli) piuttosto che codificare a fondo la funzione per ottenere un valore è altrettanto utile nella programmazione funzionale quanto nell'orientamento agli oggetti.

E anche quando si esegue una programmazione orientata agli oggetti, molti di questi principi si applicano anche alla progettazione di metodi negli oggetti.

— Telastyn
fonte