Programmation fonctionnelle vs programmation orientée objet [fermé]

vous ne devez pas nécessairement choisir entre les deux paradigmes. Vous pouvez écrire des logiciels avec une architecture OO en utilisant de nombreux concepts fonctionnels. de la FP et de la programmation orientée objet sont orthogonaux dans la nature .

par exemple C#. On pourrait dire que c'est surtout de L'OOP, mais il y a beaucoup de concepts et de constructions de FP. Si vous considérez Linq , les constructions les plus importantes qui permettent à Linq d'exister sont de nature fonctionnelle: lambda expressions .

un autre exemple, F#. Vous pourriez dire que C'est surtout FP, mais il ya beaucoup de concepts et de constructions OOP disponibles. Vous pouvez définir des classes, des classes abstraites, des interfaces, gérer l'héritage. Vous pouvez même utiliser la mutabilité quand elle rend votre code plus clair ou quand elle augmente considérablement les performances.

beaucoup de langues modernes sont multi-paradigme.

lectures recommandées

comme je suis dans le même bateau (OOP background, learning FP), je vous suggérerais quelques lectures que j'ai vraiment appréciées:

• Programmation Fonctionnelle pour tous les jours .NET Développement , par Jeremy Miller. Un grand article (bien que mal formaté) montrant de nombreuses techniques et des exemples pratiques, du monde réel de FP sur c#.

• Monde Réel Functional Programming , par Tomas Petricek. Un grand livre qui traite principalement des concepts de FP, en essayant d'expliquer ce qu'ils sont, quand ils devraient être utilisés. Il y a de nombreux exemples à la fois dans F# et C#. Aussi, le blog de Petricek est une excellente source d'information.

la Programmation Orientée Objet, propose:

1. Encapsulation, à
   • mutation de contrôle de l'état interne
   • accouplement limite à la représentation interne
Sous-typage
2. , permettant:
   • substitution de types compatibles (polymorphisme)
   • un moyen rudimentaire de partager la mise en œuvre entre les classes (succession de la mise en œuvre)

la programmation fonctionnelle, à Haskell ou même à Scala, peut permettre la substitution par un mécanisme plus général de classes de type. L'état interne Mutable est soit découragé, soit interdit. L'Encapsulation de la représentation interne peut également être réalisé. Voir Haskell vs OOP pour une bonne comparaison.

Norman affirme que "l'Ajout d'un nouveau genre de chose à un programme fonctionnel peut exiger éditer de nombreuses définitions de fonctions pour ajouter un nouveau cas."dépend de la façon dont le code fonctionnel a employé des classes de type. Si la correspondance de modèle sur un type de données abstraites particulier est répandue dans une base de données, vous souffrirez en effet de ce problème, mais il est peut-être un mauvais design pour commencer.

révisé suppression de la référence aux conversions implicites lors de la discussion des classes de type. Dans Scala, les classes de type sont encodées avec des paramètres implicites, pas les conversions, bien que les conversions implicites soient un autre moyen d'obtenir la substitution de types compatibles.

1. si vous êtes dans un environnement fortement concurrent, alors la programmation fonctionnelle pure est utile. L'absence d'état mutable rend la concurrence presque insignifiante. Voir Erlang.

2. dans un langage multiparadigm, vous pouvez vouloir modéliser certaines choses fonctionnellement si l'existence de l'état mutable est un détail de mise en œuvre, et donc FP est un bon modèle pour le domaine de problème. Par exemple, voir liste des compressions dans Python ou std.plage dans le langage de programmation D. Ces sont inspirés par la programmation fonctionnelle.