Équivalent des principes SOLID pour la programmation fonctionnelle

J'ai trouvé les principes SOLID plutôt utiles pour la conception orientée objet.

Existe-t-il un ensemble de principes agnostiques similaires / équivalents, conçus pour la programmation fonctionnelle?

design-patterns functional-programming solid

— Mikera
source

FWIW, cela a été brièvement discuté sur SO il y a un an

— StuartLC

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

— paul

Cette vidéo ainsi que ces diapositives présentent les principes SOLID appliqués à la programmation fonctionnelle. Ils utilisent tous deux le langage Clojure à titre d'exemple, mais les principes sont valables dans d'autres langues.

— mascip

slideshare.net/RichardWarburton/…

— Ray Tayek

voir aussi: La programmation fonctionnelle est-elle un sur-ensemble d'objets orientés?

— moucher

Réponses:

C'est un peu difficile de trouver des équivalents mais je peux essayer:

S (SRP) dans FP une fonction crée TOUJOURS la même sortie pour les mêmes arguments, on parle de transparence référentielle.
O (OCP) dans FP, il existe un concept appelé types de données algébriques, regardez comment il est lié aux hiérarchies de classes et quel problème tentent à la fois de résoudre ¹
L (LSP) Le principe de substitution de Liskov est Contravariance ²
D (DIP) en programmation fonctionnelle générale permet d'abstraction par composition de fonction, il existe également un autre mécanisme à l'aide de la théorie des catégories (par exemple monoïde ou foncteur), pour "Injection de dépendance" ³

— AndreasScheinert
source

Je réfléchis encore à la manière dont vous êtes passé du principe de responsabilité unique à la transparence référentielle . Ces deux ne sont pas liés. SRP concerne une fonction ayant un seul but. Il peut être ou ne pas être référentiellement transparent, à cet égard.

— Goran Jovic

Ah, mon mauvais - je comprends maintenant. Ce sont des équivalents dans le sens d’être des principes et de former le même acronyme, et non dans le sens de sens identique ou similaire. Désolé pour le downvote!

— Goran Jovic

C’est bien la façon prévue de le lire. J'ai essayé de décrire une cartographie de ces termes dans le contexte de fp.

— AndreasScheinert

Man je déteste que vous ne pouvez pas éditer un commentaire, en fait les choses devraient signifier au moins quelque chose de similaire.

— AndreasScheinert

Peut-être que les fonctions d'ordre supérieur peuvent fournir une sorte d'injection de dépendance: vous injectez une fonction concrète en tant que paramètre dans une fonction générique (d'ordre supérieur).

— Giorgio

SOLID s'avère être une bonne idée pour les domaines fonctionnel / impératif aussi.

SRP - «Ne faites qu'une chose» a été empruntée à la programmation impérative. Avoir de petites fonctions ciblées, c'est bien.

OCP - Vous permettre de modifier les comportements sans modifier le code est une bonne chose. La programmation fonctionnelle utilise davantage les fonctions d'ordre supérieur que l'héritage, mais le principe est valable.

LSP - Le respect de certains contrats d'interface est tout aussi bon en programmation fonctionnelle qu'en orientée objet. Si une fonction de tri utilise un comparateur, vous vous attendriez à ce que le comportement '0 est égal, inférieur à fournit des résultats négatifs, supérieur à celui des résultats positifs.

ISP - La plupart des langages fonctionnels ont encore des structures. La spécification du plus petit ensemble de données requis par une fonction est toujours une bonne pratique. Exiger l'interface la moins spécifique aux données (pourquoi utiliser des listes d'ints alors que les énumérations de T fonctionnent aussi bien?) Reste une bonne pratique.

DIP - Spécifier des paramètres à une fonction (ou une fonction d'ordre supérieur pour les récupérer) plutôt que de coder en dur la fonction pour obtenir une valeur est tout aussi bon en programmation fonctionnelle qu'en orientée objet.

Et même lorsque vous effectuez une programmation orientée objet, nombre de ces principes s'appliquent également à la conception de méthodes dans les objets.

— Telastyn
source