IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Faut-il éviter d'utiliser des classes et s'appuyer autant que possible sur une approche fonctionnelle ? Un point de vue d'Andy Peterson
Basé sur son expérience en entreprise avec Typescript

Le , par Patrick Ruiz

169PARTAGES

10  1 
Il existe une panoplie de manières d’aborder la programmation informatique. Dans le jargon du milieu, on parle de paradigme de programmation. En incluant celui dit impératif, on répertorie à minima trois grandes familles et leurs dérivés. Certaines de ces approches font quasiment office de norme dans l’actuelle industrie de la programmation informatique. C’est par exemple le cas du paradigme orienté objet sur lequel il est possible de s’appuyer en Typescript qui, comme d’autres langages, donne également la possibilité de faire usage de l’approche fonctionnelle.

Dans une publication parue il y a peu, Andy Peterson de l'entreprise Atomic Object explique pourquoi il ne fait pas un usage systématique des classes et s’appuie autant que possible sur une approche fonctionnelle. En fait, il s’agit d’une posture globale de l’équipe de développeurs de l’entreprise spécialisée en développement web, mobile, desktop et dispositifs matériels : programmation fonctionnelle à la place de la POO lorsque possible.

L’un des principaux aspects qui oppose programmeurs orienté objet et fonctionnels est celui de la gestion de la propriété des objets au sein des bases de code – la notion d’état. Grosso modo, l’avis d’Andy Peterson tiré de son expérience dans l’écosystème Typescript est que l’approche fonctionnelle rend plus simple la gestion des états que la POO. Ce dernier s’aligne sur celui d’Ilya Suzdalnitski – ingénieur en informatique chez Replicon – qui souligne que la gestion des états est plus complexe avec l’approche orientée objet surtout pour des bases de code importantes.


Andy Peterson

« L’état en lui-même est assez inoffensif. La grosse difficulté naît avec ceux dits mutables surtout s’ils sont partagés. Le cerveau humain est la machine la plus puissante de l'univers. Cependant, nos cerveaux sont vraiment piètres au jeu de la gestion des états. Il est beaucoup plus facile de raisonner au sujet d'un morceau de code si vous pensez seulement à ce que celui-ci fait et non aux variables qu'il modifie au sein de la base de code. Programmer avec des objets mutables s'apparente à de la jonglerie mentale. Je ne sais pas ce qu'il en est de vous autres, mais moi je pourrais jongler avec deux balles. Donnez-moi trois balles ou plus et je les lâcherai toutes. Pourquoi donc essayons-nous d'accomplir cet acte tous les jours au travail ? Malheureusement, la gestion des objets mutables est au cœur même de la programmation orientée objet. Le seul but de l'existence de méthodes sur un objet est de pouvoir modifier ses propriétés », soulignait-il à mi-parcours de l’année précédente.

D’après l’ingénieur de Replicon la racine des maux avec la POO telle que pratiquée via des langages comme Java ou C# est qu’elle n’est pas implémentée telle qu’Alan Kay l’a conçue. « On n’aurait jamais dû parler de concepts comme l’héritage, le polymorphisme ou avoir à traiter avec une myriade de patrons de conception », souligne-t-il. Ilya Suzdalnitski accuse les langages phares du moment de mettre en avant une POO qui ne s’aligne pas sur la définition originelle de l’encapsulation et sur la communication par messages entre programmes indépendants.

« En Erlang, on pratique la programmation orientée objet sous sa forme la plus pure. À l’inverse des langages de programmation phares, Erlang s’appuie sur l’idée centrale de la POO – les messages. Dans ce langage, les objets communiquent via des messages immuables », avait-il indiqué. Au travers de cet exemple, l’ingénieur de Replicon suggérait que programmation fonctionnelle et programmation orientée objet « pure » sont une seule et même chose. En droite ligne avec ce détail, il avait surtout mis en avant la supériorité de la programmation fonctionnelle vis-à-vis de la POO telle que pratiquée avec Java, C#, C++ et autres.

Richard Feldman (l’auteur de « Elm in Acrion ») est d’avis que « l’on est quelque part au milieu d’une transition du style programmation orientée objet vers celui dit fonctionnel. » « Des langages de programmation comme Kotlin prennent à la fois la programmation orientée objet et celle dite fonctionnelle en charge. C’est quelque chose que vous n’auriez pas vu dans une FAQ du langage Java dans les années ‘90. En fait, de plus en plus de langages mettent en avant le support du style fonctionnel en avant comme argument de vente. Les développements en cours laissent penser que de plus en plus d’acteurs de la filière sont d’accord que l’approche fonctionnelle est bonne », ajoute-t-il.

Il y a quelques mois, l’étude « Emploi développeur 2018 » est parue sur cette plateforme. En tête de liste des langages les plus demandés et les mieux payés, on retrouve Java. Sa première présentation officielle s’est faite le 23 mai 1995 au SunWorld comme langage de programmation structuré, impératif et orientée objet. C’est Java 8 (sorti en 2014) qui est venu mettre les développeurs qui font usage de ce langage de programmation sur les rails du style fonctionnel au travers des expressions lambdas. En fait, la remarque de Feldman vaut pour bon nombre de langages de cette enquête dvp pour lesquels on note que de plus en plus de livres orientés programmation fonctionnelle paraissent.


« C’est le signe que quelque chose a changé des années ‘90 à nos jours. L’approche fonctionnelle attire de plus en plus d’acteurs de la filière. Ce n’est plus qu’une question de temps pour la voir s’imposer », a conclu Feldman.

Source : billet de blog

Et vous ?

Partagez-vous l’avis selon lequel la POO introduit plus de complexité que l’inverse pour des bases de code importantes ?
Quelle est votre expérience avec l’approche fonctionnelle ? Introduit-elle moins de complexité que l’approche orientée objet ?
Partagez-vous l’avis selon lequel l’approche fonctionnelle finira par s’imposer comme norme ?

Voir aussi :

La programmation orientée-objet est-elle dépassée ? Une école en sciences informatiques l'élimine de son programme d'introduction
Faut-il éviter de distraire les débutants avec l'orientée objet ?
Comment pourriez-vous expliquer l'orienté objet ? Steve Jobs a essayé d'expliquer ce concept

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de air-dex
Membre expert https://www.developpez.com
Le 16/03/2020 à 15:17
Le nom de "Ilya Suzdalnitski" mentionné ici m'a rappelé quelque chose quand je l'ai lu. Il me semblait déjà l'avoir vu quelque part sur DVP. Après recherche, je suis tombé sur ces deux articles :

Deux articles où il y a des évangélistes de la programmation fonctionnelle qui disent que la programmation fonctionnelle c'est mieux que la POO. On se demande bien pourquoi.

Et c'est encore pareil ici. Allez-y si vous avez envie de rapartir dans un débat "fonctionel ou objet ?" de plusieurs pages comme pour les deux autres articles (respectivement 7 et 11 pages).
10  1 
Avatar de Pyramidev
Expert éminent https://www.developpez.com
Le 16/03/2020 à 19:08
Citation Envoyé par mermich Voir le message
Approche fonctionnelle n'est absolument pas contradictoire avec classes, il suffit de ne pas avoir de variable d'instances et ni de variable static par exemple :
Code : Sélectionner tout
1
2
3
4
5
6
public class Personne
{
      DateTime  naissance;
      public Personne(DateTime  naissance){this.naissance = naissance;}
      public double GetAge()        { return (DateTime.Now - naissance).TotalSeconds; }
}
En fait, dans cet exemple, la méthode GetAge() va à l'encontre de la programmation fonctionnelle, car elle est non pure, à cause de l'appel à DateTime.Now.
D'ailleurs, si on construit du code par dessus qui appelle Personne.GetAge, alors ce code ne sera pas testable, car son comportement dépendra directement de la date et heure courante, qui n'est pas paramétrable.

Pour rendre ce code fonctionnel, au lieu d'appeler directement DateTime.Now dans le code "bas niveau", il faut passer de paramètre en paramètre la date et heure courante, soit sous forme de variable de type DateTime, soit sous forme de callback qui ne prend pas de paramètre et dont le type de retour est DateTime.
Une première conséquence est que le code sera testable : lors des tests unitaires, on passe un paramètre sous contrôle où on choisit la date et heure fixée que l'on veut. En production, on passera la vraie date et heure ou la callback qui retourne la vraie date et heure.
Une deuxième conséquence est que, du code appelé vers le code appelant, on conserve une dépendance explicite sous forme de paramètre : en lisant les signatures des fonctions, y compris l'appelant de l'appelant de l'appelant etc., on sait que cette date et heure fait partie des entrées.
9  0 
Avatar de defZero
Membre extrêmement actif https://www.developpez.com
Le 16/03/2020 à 15:26
Avec le cloud, on recentralise tout dans des serveurs, comme sur les mainframes
@xbrossard
Sauf qu'appart la couche de donné, tous le travail est fait de plus en plus côté client avec HTML5.
Bon, forcement la validation, l'auth, ...etc côté serveur, mais il faut bien qu'il serve à quelque chose .

Avec le retour de la programmation fonctionnelle, on redécoupe tout en fonction
@xbrossard
Et en objet on redécoupe tout en classes, méthodes, accesseurs, ...etc et il faut tout un framework de test avec Mock et compagnies pour tester ne serait-ce qu'une petite classe isolé.
C'est pas forcement pertinent de devoir sortir le bazooka pour dégommer une mouche.

Enfin, concrètement, un dev s'adapte à la problématique du moment.
Si le fonctionnel répond mieux à ses besoins, tant mieux si le langage l'y autorise.
Si l'OO répond mieux au problème, alors banco.
Par contre, dans tous les cas il va devoir découper sont problème en sous problèmes et donc en bloc fonctionnel que ce soit en impératif, fonctionnel ou objet.
Si sont langage de prédilection lui laisse plus d’amplitude, c'est plutôt une bonne nouvelle de mon point de vue.
Et puis bon, si vous manipulez de la data, vous faites déjà du fonctionnel (si c'est bien fait ).

bienvenu dans le monde des années 70
@xbrossard
Et oui, ...du temps ou les programmes ne plantait quasiment pas lorsqu'ils sortaient en version final.
Ou les programmes les plus fous tenaient sur 20 disquettes 8-5" et faisaient leurs taf sans besoin de patches.
Le temps ou les sources étaient fournit au client sous forme de livret fournit dans la boite du logiciel, des fois que le logiciel lui appartienne .
Le bon temps pour le coup.
Si on était encore capable de faire des soft comme dans les années 70, mais avec la puissance de calcule actuel, je croit que vous seriez le premiers content de la vélocité obtenue.
Pour l'instant, la montée en puissance à juste permit aux plus grand nombre de dév d'être moins regardant sur la qualité et les perfs , mais ça commence à ce voire avec la stagnation des perfs de nos machine.
Enfin, je pense que c'est aussi ce phénomène qui explique, du moins en partie, l'augmentation exponentiel de nouveaux langages "remplaçant du C" ces dernières années.
9  1 
Avatar de L33tige
Membre expérimenté https://www.developpez.com
Le 16/03/2020 à 8:49
"lorsque possible"

Bah en JS c'est tout le temps possible, c'est juste que, est-ce raisonnable ?
7  0 
Avatar de xbrossard
Membre régulier https://www.developpez.com
Le 16/03/2020 à 9:39
Avec le cloud, on recentralise tout dans des serveurs, comme sur les mainframes
Avec le retour de la programmation fonctionnelle, on redécoupe tout en fonction

bienvenu dans le monde des années 70
11  4 
Avatar de yahiko
Rédacteur/Modérateur https://www.developpez.com
Le 18/03/2020 à 7:51
J'invite tout de même tout le monde à lire l'article original dont le propos n'est pas complètement retranscrit ici.

Tout d'abord, l'auteur du post original précise bien qu'il parle de son expérience avec le langage et l'écosystème TypeScript et admet que son propos aurait pu être différent s'il avait été un expert de Java ou C#, langages qui ont des mécanismes bien plus poussés pour gérer les classes que ne le permet TypeScript (et encore moins ECMAScript).

L'un des reproches qu'il adresse à structuration du code avec des classes est qu'on a tendance, via l'héritage et la surcharge de fonctions, d'élargir les responsabilités des méthodes tout en gardant le même nom initial. Une simple méthode nommée "update" finissant par faire le café. Je ne sois pas sûr que ce soit le concept de classe qui soit à blâmer ici, davantage de la discipline, mais les classes favorisent peut-être peu trop la réutilisation des noms.

Un autre reproche c'est que l'organisation du code avec des classes rend la base de code paradoxalement moins modulaire car on abouti régulièrement à des méga-classes avec des enfilades de propriétés et méthodes. A moins que TypeScript améliore son concept de classe partielle (les "mixins" n'étant qu'un bidouillage pas totalement satisfaisant selon moi) comme on peut le retrouver dans d'autres langages, C# par exemple, il est clair qu'en TypeScript, tout faire à base de classes n'est pas une bonne idée si on veut tendre vers la modularité. Il est effectivement préférable comme le remarque l'auteur d'utiliser le concept de modules, normalisé en ECMAScript qui plus est.

L'auteur fait également mention de la difficulté à bien gérer les changements d'états interne des classes ce qui le pousse à utiliser une approche basée sur les fonctions (ce qui ne signifie pas qu'il s'agit d'une approche fonctionnelle au sens pur du terme). Mon opinion sur la question des états étant qu'ils sont inévitables dans une application du monde réel, mais qu'il faut bien sûr les limiter au maximum, les canaliser et les maîtriser, en repoussant le plus tard possible leur apparition dans le code, afin de limiter l'explosion combinatoire au moment d'élaborer les cas de tests.
6  0 
Avatar de ciola
Membre du Club https://www.developpez.com
Le 16/03/2020 à 21:52
"Le cerveau humain est la machine la plus puissante de l'univers." Ben voyons, voilà une affirmation à l'image du dit cerveau. Quelle prétention !
5  0 
Avatar de pboulanger
Membre éprouvé https://www.developpez.com
Le 17/03/2020 à 0:14
chaque paradigme de programmation a ses avantages et ses inconvénients: chacun a été conçu pour résoudre une catégorie de problèmes. A chaque problème son outil... La POO est malheureusement survendu en école et trop mis en avant par certains langages...
5  0 
Avatar de L33tige
Membre expérimenté https://www.developpez.com
Le 16/03/2020 à 16:07
Citation Envoyé par defZero Voir le message

Le bon temps pour le coup.
Si on était encore capable de faire des soft comme dans les années 70, mais avec la puissance de calcule actuel, je croit que vous seriez le premiers content de la vélocité obtenue.
Pour l'instant, la montée en puissance à juste permit aux plus grand nombre de dév d'être moins regardant sur la qualité et les perfs , mais ça commence à ce voire avec la stagnation des perfs de nos machine.
Enfin, je pense que c'est aussi ce phénomène qui explique, du moins en partie, l'augmentation exponentiel de nouveaux langages "remplaçant du C" ces dernières années.
Rien à voir, la complexité et les demandes sont de loin pas les mêmes par rapport à 1970, je te donne un contre exemple, faire le même code aujourd'hui qu'en 1970 ça demande moins de temps pour moins de lignes de code, quand aux bugs, c'est pareil, une app sortie en prod doit avoir un nombre de bug qui tends vers zéro. La seul différence, c'est qu'à l'époque on sortait pas tant que c'était pas parfait, maintenant si tu fais ça, tu mets la clef sous la porte avant même d'avoir sorti ton produit.
5  1 
Avatar de Neckara
Inactif https://www.developpez.com
Le 10/05/2020 à 14:51
Pour les variables "globales", on peut penser à certains DP de Factory/Singleton/Lazy/Proxy.

Par exemple, je veux charger une image utilisée dans plusieurs bouts de codes, et je ne veux la charger qu'une fois, et que lorsqu'elle sera utilisé pour la première fois.

Certes, on pourrait avoir une variable "contexte" qu'on donne en paramètre de chaque fonctions. Le problème, c'est que suivant le langage, il n'est pas forcément évident de rajouter des choses à cette variable "contexte" de manière propre. Et surtout, il faut garantir que cette variable "contexte" ne soit instanciée qu'une seule fois, donc on se retrouve avec un des problèmes qu'on souhaitait résoudre avec cette variable "contexte".
4  0