Programmation fonctionnelle vs programmation orientée objet
J'ai été principalement exposé à la programmation OO et j'ai hâte d'apprendre un langage fonctionnel. Mes questions sont:
- Quand choisissez-vous une programmation fonctionnelle plutôt que orientée objet?
- Quelles sont les définitions de problèmes typiques où la programmation fonctionnelle est un meilleur choix?
Quand choisissez-vous une programmation fonctionnelle plutôt que orientée objet?
Lorsque vous anticipez une évolution différente du logiciel:
Les langages orientés objet sont utiles lorsque vous avez un ensemble fixe d'opérations sur des objets , et à mesure que votre code évolue, vous ajoutez principalement de nouvelles choses. Cela peut être accompli en ajoutant de nouvelles classes qui implémentent des méthodes existantes et les classes existantes sont laissées seules.
Les langages fonctionnels sont bons quand vous avez un ensemble fixe de choses , et à mesure que votre code évolue, vous ajoutez principalement de nouvelles opérations sur des objets existants. Cela peut être accompli en ajoutant de nouvelles fonctions qui calculent avec les types de données existants, et les fonctions existantes sont laissées seules.
Lorsque l'évolution va dans le mauvais sens, vous avez des problèmes:
L'ajout d'une nouvelle opération à un programme orienté objet peut nécessiter l'édition de nombreuses définitions de classe pour ajouter une nouvelle méthode.
L'ajout d'un nouveau type d'objet à un programme fonctionnel peut nécessiter l'édition de nombreuses définitions de fonctions pour ajouter un nouveau cas.
Ce problème est connu depuis de nombreuses années. en 1998, Phil Wadler l'a surnommé le "problème d'expression" . Bien que certains chercheurs pensent que le problème de l'expression peut être résolu avec des fonctionnalités de langage telles que mixins, une solution largement acceptée n'a pas encore été trouvée.
Quelles sont les définitions de problèmes typiques où la programmation fonctionnelle est un meilleur choix?
Langages fonctionnels Excel pour manipuler des données symboliques sous forme d'arborescence. Les compilateurs en sont un exemple favori. Les langages source et intermédiaire changent rarement (essentiellement les mêmes choses ), mais les auteurs de compilateurs ajoutent toujours de nouvelles traductions et améliorations de code ou optimisations (nouvelles opérations sur les choses). La compilation et la traduction sont plus généralement des "applications révolutionnaires" pour les langages fonctionnels.
Vous n'avez pas nécessairement à choisir entre les deux paradigmes. Vous pouvez écrire un logiciel avec une architecture OO en utilisant de nombreux concepts fonctionnels. FP et OOP sont de nature orthogonale .
Prenons par exemple C #. Vous pourriez dire que c'est principalement de la programmation orientée objet, mais il existe de nombreux concepts et constructions FP. Si vous considérez Linq , les constructions les plus importantes qui permettent à Linq d’exister sont de nature fonctionnelle: expressions lambda .
Un autre exemple, F #. Vous pouvez dire qu'il s'agit principalement de PF, mais il existe de nombreux OOP concepts et constructions disponibles. Vous pouvez définir des classes, des classes abstraites, des interfaces, gérer l'héritage. Vous pouvez même utiliser la mutabilité pour rendre votre code plus clair ou pour augmenter considérablement les performances.
Beaucoup de langues modernes sont multi-paradigmes.
Lectures recommandées
Comme je suis dans le même bateau (fond OOP, apprendre la PF), je vous suggère quelques lectures que j'ai vraiment appréciées:
Programmation fonctionnelle pour le développement .NET au quotidien, par Jeremy Miller. Un excellent article (bien que mal formaté) montrant de nombreuses techniques et exemples pratiques réels de FP sur C #.
Programmation fonctionnelle dans le monde réel, de Tomas Petricek. Un excellent livre qui traite principalement de FP concepts, en essayant d’expliquer ce qu’ils sont, quand ils devraient être utilisés. Il existe de nombreux exemples en F # et en C #. En outre, blog de Petricek est une excellente source d'informations.
La programmation orientée objet offre:
- Encapsulation, à
- mutation de contrôle de l'état interne
- couplage limite à la représentation interne
- Sous-typage permettant:
- substitution de types compatibles (polymorphisme)
- un moyen brut de partager l'implémentation entre les classes (héritage d'implémentation)
La programmation fonctionnelle, en Haskell ou même en Scala, peut permettre une substitution via un mécanisme plus général des classes de types. L'état interne modifiable est soit découragé, soit interdit. L'encapsulation de la représentation interne peut également être réalisée. Voir Haskell vs OOP pour une bonne comparaison.
L'affirmation de Norman selon laquelle "L'ajout d'un nouveau type d'objet à un programme fonctionnel peut nécessiter la modification de nombreuses définitions de fonctions pour ajouter un nouveau cas." dépend de la manière dont le code fonctionnel a utilisé les classes de types. Si la correspondance de modèle sur un type de données abstrait particulier est répartie dans une base de code, vous souffrirez effectivement de ce problème, mais il s'agit peut-être d'une conception médiocre pour commencer.
ÉDITÉ Suppression de la référence aux conversions implicites lors de la discussion sur les classes de types. Dans Scala, les classes de types sont codées avec des paramètres implicites, et non des conversions, bien que les conversions implicites soient un autre moyen de remplacer efficacement des types compatibles.
Si vous êtes dans un environnement fortement concurrentiel, la programmation fonctionnelle pure est utile. L'absence d'état mutable rend la concurrence presque triviale. Voir Erlang.
Dans un langage multiparadigm, vous souhaiterez peut-être modéliser certaines choses de manière fonctionnelle si l'existence d'un état mutable est un détail d'implémentation, et donc FP est un bon modèle pour le domaine du problème. Par exemple, voir les compréhensions de liste dans Python ou std.range dans le langage de programmation D. Ceux-ci sont inspirés par la programmation fonctionnelle.