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 !

La POO n'est pas meilleure que la programmation fonctionnelle et vice versa, d'après Dave Farley
D'avis que c'est au programmeur de choisir le paradigme qui convient le mieux au problème à résoudre

Le , par Patrick Ruiz

34PARTAGES

12  0 
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 de la programmation orientée objet dont l’usage prédominant dans la filière peut laisser penser qu’il s’agit d’une meilleure approche que la programmation fonctionnelle. Des intervenants de renom de la filière comme Dave Farley sont d’avis qu’aucun de ces paradigmes n’est supérieur à l’autre et qu’il revient au programmeur de choisir celui qui convient le mieux au problème à résoudre.

La programmation orientée objet consiste en la définition et l’interaction de briques logicielles appelées « objets. » Un objet représente un concept, une idée ou toute entité du monde physique, comme une voiture, une personne ou encore une page d'un livre. Il possède une structure interne et un comportement, et il sait interagir avec ses pairs. Il s'agit donc de représenter ces objets et leurs relations ; l'interaction entre les objets via leurs relations permet de concevoir et réaliser les fonctionnalités attendues, de mieux résoudre le ou les problèmes.


La programmation fonctionnelle pour sa part peut être considérée comme l'opposé de la programmation orientée objet. Les objets encapsulent un état interne ainsi qu'une collection de méthodes qui permettent de modifier cet état. Les programmes consistent à appliquer les bons changements à ces états. La programmation fonctionnelle impose d'éviter au maximum ces changements d'états en travaillant sur des données qui traversent un flux de fonctions.





« Ma position n'est pas que je déteste la programmation fonctionnelle et que j'aime la POO ou vice versa, mais plutôt que je considère chacune de ces approches comme des outils plutôt que comme des sujets de débats futiles », déclare Dave Farley.



La sortie de Dave Farley fait pourtant suite à des développements antérieurs qui suggèrent de passer à l’approche fonctionnelle

En effet, à mi-parcours de l’année 2019, Ilya Suzdalnitski de l’entreprise Replicon affirmait que « considérer la programmation orientée objet comme standard de l’industrie pour l’organisation des bases de code est, pour lui, une grosse erreur. » Son développement laissait filtrer que l’usage de la programmation orientée objet dévie l’attention des développeurs de ce qui doit la retenir : la résolution des problèmes. « L’approche orientée objet introduit plus de complexité que l’inverse surtout pour des bases de code importantes », avait-il souligné avant d’ajouter qu’ « il est difficile d’écrire du code orienté objet aisé à maintenir, les tests unitaires sont difficiles à appliquer à une base de code montée suivant l’approche orientée objet, le refactoring de code est une vraie galère sans des outils comme Resharper. »

L’ingénieur de Replicon avait insisté sur ceci que 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 », avait-il souligné. Ilya Suzdalnitski accusait 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.

« Le but ultime de tout développeur de logiciel devrait être d'écrire du code fiable. Rien d'autre n'a d'importance si le code est bogué et peu fiable. Et quelle est la meilleure façon d'écrire un code fiable ? Simplicité. La simplicité est le contraire de la complexité. Erlang est probablement le langage le plus fiable au monde. La majeure partie de l'infrastructure mondiale des télécommunications (et donc de l'Internet) s'appuie sur ce dernier. Certains des systèmes écrits en Erlang ont une fiabilité de 99.999999999 % », avait-il insisté.



« L’on est quelque part au milieu d’une transition du style programmation orientée objet vers celui dit fonctionnel », estime Richard Feldman. « 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 2022 » 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.

Source : Dave Farley

Et vous ?

POO ou fonctionnel : lequel des paradigmes a eu le plus d’influence sur vous ? Pour quelles raisons ?
Quelle est votre expérience avec l’approche fonctionnelle ? Introduit-elle moins de complexité que l’approche orientée objet ?
Voyez-vous l'impact de l'approche fonctionnelle s'étendre au point qu'elle s'impose comme une norme ?
Votre expérience des tests unitaires et du refactoring de code a-t-elle souvent été pénible sur des bases de code montées en s’appuyant sur l’approche orientée objet ? Si oui, pourquoi ?
Partagez-vous l’avis selon lequel la gestion des états est plus complexe avec la POO qu’avec l’approche fonctionnelle pour des bases de code importantes ?

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 OuftiBoy
Membre éprouvé https://www.developpez.com
Le 01/08/2024 à 14:13
Citation Envoyé par eric44000 Voir le message
L'approche fonctionnelle est réputée pour avoir une complexité moindre que l'OO. Mais on pourrait le dire également entre l'OO (C++) et l'impératif (C). Et parfois entre le C et l'assembleur (bien que les compilateurs C soient très performants).
J'aime bien le concept de la POO, sur le papier, ça semble être une bonne solution. Mais au fil des années, force est de constater qu'elle engendre des sources imbuvables et incompréhensibles. La notion d'héritage fait qu'on se retrouve avec des couches et couches d'abstractions, et cela devient vite très lourd à comprendre. Je répète souvent d'on "lit" 100x plus un code source qu'on "écrit" ce dernier. Si on veut essayer de garder le contrôle, il faut:
- Programmer pour des interfaces
- préférer la composition à l'héritage

L'encapsulation, n'est pas non plus vraiment un plus, ça complexifie plus que ça n'aide. Avant, en programmation structurée, on avait des fonction du genre open(&file) où file était une "structure" et maintenant on fait file.open() où file est on "objet". Il ne serait jamais venu à quelqu'un l'idée de faire sqrt(&File) (calculer la racine carrée d'un nombre). L'encapsulation n'apporte pas vraiment un plus, on "lie" les data avec les fonctions qui peuvent les utiliser, donc on crée une "class", et arrive vite les soucis de l'héritages.

Le polymorphisme et/ou la surcharge des opérateur, ça ne rend pas non plus le code plus clair. Quand on lit un source et qu'on tombe sur un "a = a + b" (a et b étant des objets), on ne sait pas dire exactement ce que fait le "+". Il faut connaître les couches en dessous pour comprendre.

Je n'ai rien contre la POO, mais il faut qu'elle soit extrêmement bien appliquée. Et tout le monde sait qu'on a pas toujours le temp de bien penser les choses.

Citation Envoyé par eric44000 Voir le message
Mais il arrive aussi (et c'est très souvent le cas) que la complexité ne soit pas rédhibitoire. Et si c'était le cas, rien n'empêche de programmer en OO et de faire une application fonctionnelle pour la partie critique (certains langages sont même multiparadigme).
Il faut bien distinguer la complexité d'un problème de la complexité de la solution de ce problème. Avec la notion "d'héritage", il y le biais qu'on essaye de "prévoir" dès le début comment le problème va évoluer, et très vite on se retrouve avec des couches sur des couches. Je tente de m'en tenir au concept KISS.

Citation Envoyé par eric44000 Voir le message
Donc vouloir faire du paradigme fonctionnel un standard, oui mais pas à cause de la complexité. L'argument premier est la sécurité du code. Reste que la majorité du code est écrit en OO et que cela demande beaucoup de personnel pour le maintenir.
La sécurité du code est certes très importante, mais cette sécurité ne doit pas être obtenue via un complexité inutile du code source, car quand le code source devient imbuvable, on a plus de risque d'introduire des problèmes de sécurité.

Ma petite conclusion:

Quelque soit le langage ou son paradigme, il faut surtout savoir ce qu'on fait, pourquoi on le fait, pourquoi on le fait d'une manière ou d'une autre, et le faire le plus simplement possible. Pour qu'un programme puisse évoluer en toute quiétude, il faut avant tout que son code source reste lisible et compréhensible le plus facilement possible.


BàV. Et Peace & Love.
3  0 
Avatar de OuftiBoy
Membre éprouvé https://www.developpez.com
Le 01/08/2024 à 19:31
Citation Envoyé par eric44000 Voir le message
Tout à fait, la complexité que Dave Farley parle est différente de la complexité que vous évoquez avec les couches et surcouches de la POO. Encore que je ne trouve pas que les notions d'héritage soient complexes.
La notion d'héritage n'est pas complexe en elle-même, mais son utilisation peut vite, elle, devenir complexe.

Citation Envoyé par eric44000 Voir le message
Je la verrai plutôt dans les design patterns (quoique tout s'apprend). Un des arguments de la POO par rapport à au paradigme impératif était que la POO évitait le "Spaghetti code" qui lui était vraiment compliqué.
Les "Design Patterns" ne sont qu'une compilation de "bonnes pratiques", sur lesquels on a posé un "formalisme". Je pense que tout le monde a plusieurs fois utilisé un "Design Pattern" sans même s'en rendre compte. Suivant le langage utilisé, certains de ces "Design Pattern" sont complétement inutiles, car les fonctionnalités du langage peut permettre de s'en passer. L'excès d'applications de ces "Design Patterns" peut vite rendre les choses plus compliquées que nécessaire. Il m'arrive aussi souvent de voir passer du code qui a abusé des ces "Design Patterns", alors qu'une solution plus simple aurait pu suffire.

Puisqu'on par cuisine , La POO aide à éviter du code "Spaghetti" , mais on se retrouve avec une "lasagne" . Ma préférence, ce sont les "raviolis" .

Citation Envoyé par eric44000 Voir le message
En fait, la POO évite la complexité avec UML mais complique tout avec les méthodes agiles. D'ailleurs SCRUM conseille de réécrire le code constamment pour entre autre éviter de complexifier l'architecture.
Si on doit trop souvent "refactoriser", c'est que le problème à traiter n'était pas clairement définit à la base, ou qu'on l'a mal compris, ou que le client l'a mal exprimé, ou qu'on a tenté de "prédire" l'avenir. Je laisse à Madame Irma le soin de prédire l'avenir, moi j'en suis incapable .

Il est plus facile de refactoriser un code bien clair et modulaire (mes raviolis) qu'un code "Spaghetti" ou "Lasagne".

Concernant UML, j'avoue que je ne suis pas fan. C'est bien souvent à cause de ces UML qu'on produit du code avec trop d'abstractions ou rempli de cas inutiles pour le problème posé. Avec l'expérience, on voit vite si ce que l'on nous demande a bien été réfléchit ou pas. Il m'arrive de laisser passer quelques réunions avant de commencer quoi que ce soit. Je laisse les choses se "décanter" d'elles mêmes.

Un des problème que l'on rencontre souvent, c'est que les besoins ne sont pas exprimés par les utilisateurs (celui qui utilise le programme au final), mais par un intermédiaire, qui a souvent une vision moins "terre à terre", ce qui n'aide pas à garder les choses le plus simple possible.

BàV et Peace & Love.
3  0 
Avatar de SQLpro
Rédacteur https://www.developpez.com
Le 05/08/2024 à 16:42
Citation Envoyé par Ryu2000 Voir le message
...J'aimais beaucoup le langage Java est en Java tout est objet....
Non, c'est aussi un langage OO (orienté objet). On y trouve des scalaires (nombre, chaines de caractères et des opérateurs sur ces scalaires. Un des rares langage purement objet est Small Talk

A +
4  1 
Avatar de OuftiBoy
Membre éprouvé https://www.developpez.com
Le 01/08/2024 à 19:59
Citation Envoyé par denisys Voir le message
Sauf si tu lit la documentation technique !
Malheureusement la "documentation technique" est souvent encore plus imbuvable que le code source . Si le code source reste clair, simple, limpide, il n'y a pas besoin de "documentation technique", qui, en plus, n'est bien souvent pas/plus mise à jour au fil de l'avancement d'un projet . La meilleur "documentation technique" est selon moi le code source en lui-même .

Citation Envoyé par denisys Voir le message
Au fait , la méthodologie dite : SCUM .
Elle inclue combien de temps , dans l'entretien et la rédaction de la documentation technique ?
Tout comme je ne suis pas fan d'UML, je ne suis pas fan de "Méthodologie". Je suis plutôt adepte du "Bon sens". Le problème des "Méthodologies", c'est un peut le même que celui d'UML, ou des "Design Patterns". A trop suivre des règles, on emprunte souvent des chemins plus compliqués que nécessaire, ce que je tente d'éviter au maximum .

Perso, je tiens à jour, en collaboration avec mon "client" (souvent mon chef de projet), un document où se trouve "ce qu'on a fait", "pourquoi on l'a fait" et "comment on l'a fait". Quand le projet évolue, on met à jour ce document ensemble (avant de modifier la moindre ligne de code), qui permet de garder à jour une "spécification" bien plus utile qu'une "documentation technique".

Mais ceci n'est que mon avis. Je ne prétend pas avoir de solution miracle. C'est mon expérience qui m'a mené à faire les choses ainsi. D'autres ont certainement d'autres besoins, dépendant de la nature du projet, j'en suis bien conscient.

Cette même expérience m'a fait conclure que le plus important, c'est de garder un code source clair et le plus simple possible.

BàV et Peace & Love.
2  0 
Avatar de walfrat
Membre émérite https://www.developpez.com
Le 02/08/2024 à 15:53
Citation Envoyé par OuftiBoy Voir le message
Malheureusement la "documentation technique" est souvent encore plus imbuvable que le code source . Si le code source reste clair, simple, limpide, il n'y a pas besoin de "documentation technique", qui, en plus, n'est bien souvent pas/plus mise à jour au fil de l'avancement d'un projet . La meilleur "documentation technique" est selon moi le code source en lui-même .

Tout comme je ne suis pas fan d'UML, je ne suis pas fan de "Méthodologie". Je suis plutôt adepte du "Bon sens". Le problème des "Méthodologies", c'est un peut le même que celui d'UML, ou des "Design Patterns". A trop suivre des règles, on emprunte souvent des chemins plus compliqués que nécessaire, ce que je tente d'éviter au maximum .

Perso, je tiens à jour, en collaboration avec mon "client" (souvent mon chef de projet), un document où se trouve "ce qu'on a fait", "pourquoi on l'a fait" et "comment on l'a fait". Quand le projet évolue, on met à jour ce document ensemble (avant de modifier la moindre ligne de code), qui permet de garder à jour une "spécification" bien plus utile qu'une "documentation technique".
Heu, alors l'UML , les design pattern, ne sont pas des méthodologie pour moi, ce sont des outils pour répondre à un problème, et certains en font une méthodologies de "toujours plier ton problème pour que ça rentre dans un design pattern". Bref il y a beaucoup de monde pour qui le but c'est d'éviter d'avoir du "bon sens", autrement dit de réfléchir.

L'usage des design pattern, c'est justement du pur bon sens : "il répond entièrement à mon problème, je l'utilise, sinon je vais devoir adapter, voir faire autrement.

Personnellement de mon côté, le plus gros manque ne sont pas des documentations techniques pour commenter le code une fois produit, mais des spécifications/prérequis techniques qui permettent de structurer la démarche du développeur, et qui mèneront à des développeurs différents à une résultat de code pour le même genre d'élément techniques relativement proche.
2  0 
Avatar de Mat.M
Expert éminent sénior https://www.developpez.com
Le 03/08/2024 à 17:39
Citation Envoyé par OuftiBoy Voir le message
Je me suis surement mal expliqué. L'UML et les "Design Patterns", je ne les vois pas non plus comme des "Méthodologies", mais bien comme des outils.
je pense que les design patterns et UML ont été crée dans un esprit "d'industrialisation " d'un projet informatique.
Bref ne pas réinventer à chaque fois la roue.
Pour ça on regarde si on a pas des objets modulaires en stock et on les réutilise ça évite de perdre son temps à faire du code supplémentaire.
Donc oui on peut parler d'outils.
2  0 
Avatar de Bousk
Rédacteur/Modérateur https://www.developpez.com
Le 13/08/2024 à 17:55
Toutes les quelques années un nouveau guru crie que machin est mieux que truc dans tel cas alors que truc est mieux que bidule dans tel autre et qu'il faut savoir faire la part des choses.
Pourquoi donner autant d'attention à un énième enfonceur de portes ouvertes ?
2  0 
Avatar de OuftiBoy
Membre éprouvé https://www.developpez.com
Le 03/08/2024 à 13:26
Citation Envoyé par walfrat Voir le message
Heu, alors l'UML , les design pattern, ne sont pas des méthodologie pour moi, ce sont des outils pour répondre à un problème, et certains en font une méthodologies de "toujours plier ton problème pour que ça rentre dans un design pattern". Bref il y a beaucoup de monde pour qui le but c'est d'éviter d'avoir du "bon sens", autrement dit de réfléchir.
Je me suis surement mal expliqué. L'UML et les "Design Patterns", je ne les vois pas non plus comme des "Méthodologies", mais bien comme des outils. Ce que je n'aime pas, c'est comme vous le dites, qu'on en abuse pour "plier" pour que ça rentre dans les clous, alors que des solutions plus existe, en réfléchissant un peu.

Citation Envoyé par walfrat Voir le message
L'usage des design pattern, c'est justement du pur bon sens : "il répond entièrement à mon problème, je l'utilise, sinon je vais devoir adapter, voir faire autrement.
Oui, c'est du bon sens, mais ça ne doit pas être utilisé pour être utilisé, si un moyen plus simple existe, je ne dis rien de plus. Il ne faut pas arriver à ce que l'on sorte un canon pour tuer une mouche.

Citation Envoyé par walfrat Voir le message
Personnellement de mon côté, le plus gros manque ne sont pas des documentations techniques pour commenter le code une fois produit, mais des spécifications/prérequis techniques qui permettent de structurer la démarche du développeur, et qui mèneront à des développeurs différents à une résultat de code pour le même genre d'élément techniques relativement proche.
Oui, le début est parfois difficile, car souvent on ne sait pas où on va. C'est pourquoi je tente de "temporiser", de laisser se décanter les choses avant de débuter vraiment.

BàV et Peace and Love.
1  0 
Avatar de
https://www.developpez.com
Le 13/08/2024 à 15:57
Citation Envoyé par esperanto Voir le message
là, je considère le lambda comme juste une expression plus simple (et plus efficace semble-t-il) que les classes anonymes, mais ça reste fondamentalement une implémentation du design pattern Stratégie, comme c'était le cas avec les classes anonymes d'ailleurs.
Je me permets d'ajouter cette petite compilation de critiques de l'excellent refactoring.guru dans laquelle apparait ta critique .

Je profite de cette source pour ajouter qu'en effet, les Design Pattern sont des outils à la structuration, mais pas seulement !
1  0 
Avatar de JPLAROCHE
Membre expérimenté https://www.developpez.com
Le 15/08/2024 à 11:53
Bonjour, sur AS400, on utilise ROO relation Objet Objet : j'avais fini par faire ma documentation technique avec des outils que j'ai faits,

a : quelles sont les relations d'objets programme entre eux en liste ou diagrammes,

b : quel son fichier utilisé par les programmes et sont-ils en mise à jour ou en écriture et leurs attributs,

c : où sont affectés les zones et quelles sont leurs descriptions dans les programme ou file et à quelles lignes,

On pouvait rapidement savoir quel impact si l'on modifiait les attributs d'une zone ou d'un fichier, d'autre part la programmation était modulaire (c'était un impératif)

pour les fichiers, nous avions un répertoire de définition des zones afin d'avoir une nomenclature unique pour l'ensemble de la base de données, RFFLD sur laquelle on s'appuyait pour décrire nos records.

Et encore plein d'autre chose.

Mais nous avions aussi une documentation simple expliquant ce que font les projets.
1  0