2 pièce(s) jointe(s)
Faut-il éviter d'utiliser des classes et s’appuyer autant que possible sur une approche fonctionnelle ?
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.
« 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 ?
:fleche: Partagez-vous l’avis selon lequel la POO introduit plus de complexité que l’inverse pour des bases de code importantes ?
:fleche: Quelle est votre expérience avec l’approche fonctionnelle ? Introduit-elle moins de complexité que l’approche orientée objet ?
:fleche: Partagez-vous l’avis selon lequel l’approche fonctionnelle finira par s’imposer comme norme ?
Voir aussi :
:fleche: La programmation orientée-objet est-elle dépassée ? Une école en sciences informatiques l'élimine de son programme d'introduction
:fleche: Faut-il éviter de distraire les débutants avec l'orientée objet ?
:fleche: Comment pourriez-vous expliquer l'orienté objet ? Steve Jobs a essayé d'expliquer ce concept
Je vois pas ou l'on veux en venir mais vu que c'est un actu le plus important c'est de dire n'importe quoi
Citation:
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...
Citation:
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..
Citation:
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:
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...
Encore une belle affirmation
"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 !
