Discussion :

[Patrick Ruiz]

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

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

[L33tige]

"lorsque possible"

Bah en JS c'est tout le temps possible, c'est juste que, est-ce raisonnable ?

[xbrossard]

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

[air-dex]

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 :

• Est-ce une grosse erreur de considérer la POO comme standard de l'industrie pour l'organisation des bases de code ?
• Pourquoi la programmation fonctionnelle n’est-elle pas la norme de l’industrie du code ?

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).

[defZero]

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.

[L33tige]

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.

[micka132]

Rien à voir, la complexité et les demandes sont de loin pas les mêmes par rapport à 1970

C'est clair qu'on ne demande pas les même choses !
Aujourd'hui un "simple" site sous entend en fait qu'il est adaptable à tous les formats et tous les navigateurs! Avec bien sûr des specs qui sont toujours sur un post-it...
Dans le domaine du jeu vidéo j'eu été surpris quand j'avais lu l'histoire de "ET" édité par Atari; Temps de dev 5 semaines pour un seul gus en 1982.
Aujourd'hui en si peu de temps tu n'as rien de commercial ( il y a bien des exceptions comme 2048, mais il y a encore plus de chance de gagner au loto).

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.

Par contre je suis d'accord avec ça, la multiplication des outils fait que bien souvent aujourd'hui on est plus proche de l'assemblage que du développement au profit de la quantité plutôt que de la qualité.

[mermich]

Bah en JS c'est tout le temps possible, c'est juste que, est-ce raisonnable ?

JS n'est pas un langage fonctionnel, c'est un langage oriente fonction c'est pas du tout la meme chose...

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

Effectivement, le cloud avec scaling automatise c'est la meme chose que les mainframes, et la prog fonctionnel c'est la meme chose que les fonctions..

Aujourd'hui un "simple" site sous entend en fait qu'il est adaptable à tous les formats et tous les navigateurs! Avec bien sûr des specs qui sont toujours sur un post-it...
Dans le domaine du jeu vidéo j'eu été surpris quand j'avais lu l'histoire de "ET" édité par Atari; Temps de dev 5 semaines pour un seul gus en 1982.
Aujourd'hui en si peu de temps tu n'as rien de commercial ( il y a bien des exceptions comme 2048, mais il y a encore plus de chance de gagner au loto).

Comparer un jeu de 1982 et un triple A actuel, c'est pas mal comme comparaison, on pourrais aussi compare la chaine d'approvisionnement du moyen age avec notre economie actuelle ce serai tout aussi pertinent.



Enfin parler juste de poo vs fonctionnel c'est reducteur, l'approche declarative existe aussi et toutes les nuances.

Prenons exemple d'une approche poo stateless type microservice:
Ce n'est pas vraiment de la poo, car stateless (a chaque appel le tout est reinstancie).
Ce n'est pas non plus du fonctionnel car il a de l'heritage de la composition et un etat lors du traitement.

Enfin on peut faire du declartif:
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 - Visualiser dans une fenêtre à part

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; }
}

Au final rien de nouveau...

[Pyramidev]

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 - Visualiser dans une fenêtre à part

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.

[calvaire]

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.

Les soft des années 80 n'ont rien a voir avec ceux d'aujourd'hui.
Aujourd'hui un logiciel offre 1000 fois plus de fonctionnalitées que ceux développé dans les 80, aujourd'hui il faut que ton logiciel puisse fonctionner avec le SGBD du client, tu dois fournir une api pour la gestion des données, et évidement fournir une ihm sexy en html5 ou 50 utilisateurs pourrons utiliser ton soft en meme temps.
c'est plus le truc en ligne de commande pouvant etre utilisé par 1 user à la fois et avec comme fonctionnalitées que 2-3 commandes ou boutons si il y'avait une IHM.

D’ailleurs c'est a cause que la monté de la complexité du développmeent uqe l'on a inventé les IDE, les tests unitaires, les gestionnaires de version et le travail d'équipe,
un exemple concret c'est celui du jeux videos, car si dans les années 80 un seul dev pouvais en 1ans faire un tetris avec 3 pauvre pixel animées aujourd'hui ce genre de soft se sera considéré comme une bouze, tu a besoin d'une équipe de graphiste, d'une équipe dédié a animations, a l'intelligence artificiel...etc. et au final tu arrive vite à sortir un jeux qui a coûté des millions.

c'est comme comparé une video fais par un youtuber seul (le dev des années 80) et hollwood ou tu as un réalisateur, un cadreur, des graphistes, des enregistreur de son...etc.
le youtuber ne fais pas de la merde au niveau du contenue hein mais d'un point de vue technique c'est a des années lumière de ce que vas te pondre un gros studio et forcément le youtuber te pondra du contue avec beaucoup de limitation comme le dev des années 80 incapable.

tu me diras on est aller sur la lune avec la puissance d'une calculatrice casio, je te répondrais oui mais le soft a crasher pendant l’atterrissage. faire des tests automatisé, de l'integration continue sa demande du temps et de l'argent et plus de dev si tu veut avancer sinon tu mettrais 50ans a faire ton soft.

je dis cela car a cette époque git ou svn n'existait pas, et je parle meme pas de genkins, de mockito, de junit...etc.

[mermich]

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.

Je sais tres bien que ce n'est pas fonctionnel pur, et si tu lis bien je n'ai pas prétendu que c’était du fonctionnel pur juste que l'on pouvait faire du fonctionnel en c#/java (meme si honnetement c'est pas la panacee). Ouais ok j'aurai dut indiquer que c'est du pseudo pur. Pour le coup des tests et de l'injections, il existe pas mal de procédés pour rendre le code testable que tu as deja cite.

[ciola]

"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 !

[Invité]

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

Pour information la POO date des années 60. https://en.wikipedia.org/wiki/Object...amming#History

[pboulanger]

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...

[yahiko]

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.

[Jiji66]

le but originel de la POO est la facilité de la réutilisation et le confinement des bug dans l'objet incriminé.

[Invité]

le but originel de la POO est la facilité de la réutilisation et le confinement des bug dans l'objet incriminé.

Encore une preuve que le confinement n'est pas très efficace, alors...

[JackIsJack]

Un exemple vaudrait mieux qu'un long discours.

Désolé l'argument des balles de jonglages ne me séduit pas : du concret !

[foetus]

le but originel de la POO est la facilité de la réutilisation et le confinement des bug dans l'objet incriminé.

le but de la POO est avant tout de regrouper les traitements/ les messages, et leurs états s'il y en a.

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.

je pense que le problème de la POO c'est d'avoir une approche "proche du réel". Et donc, il y a toujours une adaptation du "monde réel" pour qu'il devienne du code informatique ... tout en respectant le cahier des charges
Sans parler de ceux qui en rajoute parce que cela se passe "comme cela dans le réel" en utilisant des notions POO comme l'héritage qui ont des impacts lourds sur la conception mais qu'ils ne maîtrisent pas/ n’anticipent pas.

[jpouly]

J'invite tout de même tout le monde à lire l'article original dont le propos n'est pas complètement retranscrit ici.

Merci pour le résumé

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.

Élargir les responsabilités, c'est bien le but de l'héritage. Garder le même nom de méthode pour des choses complètements différentes, c'est de la fainéantise. Ou de l’incompétence.

Avant de coder, il faut réfléchir, et savoir ce qu'on veux faire. Et c'est là ou les ennuis commencent, et ce quelque soit le paradigme .

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.

Alors, de mémoire, dans un bouquin que j'ai lu quand j'étais jeune (y a un bail ) sur la programmation objet, l'auteur indiquait qu'une classe doit pouvoir être décrite sur une feuille A5.
Par décrite, je parle des membres et attributs/propriétés.

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.

Si tout est clair dans la tête du développeur et que les méthodes sont commentées comme il faut ("modification de l'attribut xxxx" par exemple), il n'y a pas de soucis à ce faire.

Si il est bordélique et sais pas ce qu'il fait, .