Équivalent de SOLID principes pour la programmation fonctionnelle
J'ai trouvé les principes SOLIDES très utiles quand on pense à la conception orientée objet.
Existe-t-il un ensemble similaire/équivalent de principes indépendants du langage adaptés à la programmation fonctionnelle?
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, cela s'appelle la transparence référentielle
- [~ # ~] o [~ # ~] (OCP) dans FP il y a un concept appelé données algébriques types, regardez comment cela se rapporte aux hiérarchies de classes et quel problème les deux essaient de résoudre 1
- [~ # ~] l [~ # ~] (LSP) Le principe de substitution de Liskov est la Contravariance 2
- [~ # ~] d [~ # ~] (DIP) dans la programmation fonctionnelle générale réalise l'abstraction grâce à la composition des fonctions, il existe également d'autres mécanismes avec l'aide de la théorie des catégories (par exemple monoïde ou foncteur), pour "Dependency Injection"
SOLID s'avère également être une bonne idée pour les domaines fonctionnels/impératifs.
SRP - 'Ne faire qu'une seule chose' a été tiré de la programmation impérative en premier lieu. Avoir de petites fonctions ciblées, c'est bien.
OCP - Vous permettre de changer les comportements sans modifier le code est bien. La programmation fonctionnelle utilise plus de fonctions d'ordre supérieur que l'héritage, mais le principe est valable.
LSP - Le respect d'un contrat d'interface est tout aussi bon en programmation fonctionnelle qu'en orienté objet. Si une fonction de tri prend un comparateur, alors vous vous attendez à ce que le "0 soit égal, inférieur à fournit des résultats négatifs, supérieur au comportement positif".
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'entiers alors que les énumérations de T fonctionnent aussi bien?) Est toujours une bonne pratique.
DIP - Spécifier les paramètres d'une fonction (ou une fonction d'ordre supérieur pour les récupérer) plutôt que de coder en dur la fonction pour aller chercher de la valeur est tout aussi bon dans programmation fonctionnelle comme orientée objet.
Et même lors de la programmation orientée objet, bon nombre de ces principes s'appliquent également à la conception de méthodes dans les objets.