Discussion :

[Patrick Ruiz]

Est-ce une grosse erreur de considérer la POO comme standard de l'industrie pour l'organisation des bases de code ?


Des manières d’approcher la programmation informatique, il y en a une panoplie. Dans le jargon du milieu, on parle de paradigme de programmation. En incluant celui dit impératif, on en compte à minima trois grandes familles et leurs dérivés. Certaines de ces approches sont connues pour ceci qu’elles corrigent les tares introduites par d’autres. C’est par exemple le cas de la programmation orientée objet dont on a appris qu’elle permet d’améliorer l’organisation des bases de code procédurales.

Dans une publication parue il y a peu, Ilya Suzdalnitski – ingénieur en informatique chez Replicon – fait savoir qu’il n’en est rien en ce qui concerne le duo programmation procédurale – programmation orientée objet. De façon brossée, 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. Ilya Suzdalnitski va même plus loin : la programmation orientée objet est un « désastre à un billion de dollars », ce, pour plusieurs raisons.

Le développement de l’ingénieur de Replicon laisse 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. D’après ce dernier, cet état de choses résulte de la nécessité que l’approche orientée objet impose de se focaliser sur la notion d’abstraction et les nombreux modèles de conception. En sus, il y aurait que l’approche orientée objet introduit plus de complexité que l’inverse surtout pour des bases de code importantes – de gros projets. Ce dernier aspect prend, d’après lui, toute sa force avec la gestion des propriétés des objets.

« 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 », souligne-t-il.

À la suite de la gestion des objets mutables qui, selon Ilya Suzdalnitski, pose problème avec l’approche orientée objet, il dresse une liste d’autres tares qui apparaissent comme des conséquences de la première : 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.

Au travers de sa publication, l’ingénieur de Replicon bat en brèche un certain nombre d’idées transmises à ceux et celles qui ont fait des études en programmation informatique. Il se veut clair : le monde réel n’est pas hiérarchisé ; la notion d’héritage telle qu’enseignée en POO n’est pas calquée sur le monde réel.

« La programmation orientée objet tente de tout modéliser comme une hiérarchie d'objets. Malheureusement, ce n'est pas ainsi que les choses fonctionnent dans le monde réel. Les objets du monde réel interagissent les uns avec les autres à l'aide de messages, mais ils sont généralement indépendants les uns des autres.

La notion d'héritage n'est pas calquée sur le monde réel. Au sein de ce dernier, l'objet parent est incapable de modifier le comportement des objets enfants lors de l'exécution. Même si vous héritez de votre ADN de vos parents, ils sont incapables d'apporter des changements à votre ADN comme bon leur semble. Vous n'héritez pas des "comportements" de vos parents, vous développez vos propres comportements », souligne-t-il.

L’ingénieur de Replicon insiste 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 », 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 », indique-t-il.

Au travers de cet exemple, l’ingénieur de Replicon suggère que programmation fonctionnelle et programmation orientée objet « pure » sont une seule et même chose. En droite ligne avec ce détail, il met surtout en avant la supériorité de la programmation fonctionnelle vis-à-vis de la POO telle que pratiquée avec Java, C#, C++ et autres. Ilya Suzdalnitski est d’avis qu’en matière de développement informatique, la simplicité doit rester de mise et la programmation fonctionnelle est la voie par excellence pour rester sur ces rails.

« 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 % », indique-t-il.

Source : billet Ilya Suzdalnitski

Et vous ?

Partagez-vous l’avis selon lequel la POO introduit plus de complexité que l’inverse pour des bases de code importantes ?

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 ?

Que pensez-vous de la programmation fonctionnelle ? Peut-elle faire office d’alternative valable à la programmation orientée objet ?

Quelle est votre expérience avec Erlang ? Serait-ce la solution ultime aux problèmes que l’auteur met sur la table ?

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

[mh-cbon]

L'article ne présente pas suffisamment d'exemples compréhensible, factuels et avec lesquels nous pourrions commencer une discussion.
Il est possible que la complexité engendrer par la poo empêche toute tentative comparative simple de déboucher, ce qui serait cocasse.

Il présente de bons arguments, mais c'est encore trop théorique pour convaincre.

Par exemple, j'ai une petite app web qui doit exécuter des actions pour lesquelles je ne souhaites pas que différents utilisateurs puissent démarrer la même action plusieurs fois en même temps. Je ne veux jamais qu'une instance à la fois.
Ça nécessite un state, ça nécessite un pointeur qui se balade, ou une globale.
Je n'arrives pas à imaginer comment le concevoir sans ces outils.

Un programmeur FP peut il éclairer sur ce genre de cas ? Est ce un mauvais exemple, une mauvaise compréhension de ma part ?

De manière plus obtus, pour forcer le trait, toute bases de données est une état global partagé pleins de mutex, d'accès concurrent etc.
bon, faut le bannir aussi ?

[Golgotha]

J'adhère pas à tout le discourt mais j'ai toujours pensé que la programmation devait rester simple et compréhensive.

Je ne pense pas qu'il faille jeter le bébé avec l'eau du bain, la POO est un bon concept qui peux être vraiment très utile. Cependant j'approuve le fait qu'il est toujours préférable de faire simple, et j'ai parfois été confronté à des aberrations, notamment en Java et en J2EE qui mélangeais un tas de concept abstrait et complexe pour, au final, effectuer des choses très simple..

En web c'est particulièrement visible, certains vous sortent des stacks de dingue (SASS, typescript, angular, gulp, webpack..) pour accoucher d'un site web qui aurait pu être réalisé avec beaucoup moins d'outils.

Au final je pense que ce n'est pas la POO le problème mais le fait de vouloir toujours prendre de gros outils pour effectuer des tâches simple. J'ai 15 ans d'expériences dans la programmation, si j'ai bien retenu quelques choses c'est qu'il faut toujours essayer de faire au plus simple si c'est possible. La simplicité est gage de contrôle (vous comprenez ce que vous faite) et de robustesse. Plus vous empilez les couches et les abstractions, plus vous prenez le risque de ne plus rien contrôler de ce qui se passe ni même comprendre ce qui ce passe.

Il n'y a aucune gloire à créer des objets ou des programmes que personne sauf vous maîtrisez.

[darklinux]

Je croyais l ' affaire réglé une bonne fois . La POO est standard de fait depuis quoi ? Java 1.1 . Certes il y a le C++ à posé les concepts avec Smalltalk . À ce niveau , c 'est vraiment un débat d ' arrière garde , cela est comme remettre en cause UML en architecture ou SQL...

[Anselme45]

Au final je pense que ce n'est pas la POO le problème mais le fait de vouloir toujours prendre de gros outils pour effectuer des tâches simple. J'ai 15 ans d'expériences dans la programmation, si j'ai bien retenu quelques choses c'est qu'il faut toujours essayer de faire au plus simple si c'est possible. La simplicité est gage de contrôle (vous comprenez ce que vous faite) et de robustesse. Plus vous empilez les couches et les abstractions, plus vous prenez le risque de ne plus rien contrôler de ce qui se passe ni même comprendre ce qui ce passe.

On a beau multiplier les outils, les méthodes et autres procédures X ou Y, les statistiques restent les mêmes depuis le début du développement informatique: 1/3 des projets répondent aux objectifs, 1/3 des projets finissent à plus ou moins fonctionner avec plein d'objectifs non-tenus et 1/3 des projets sont tout simplement abandonnés car trop malades!

Quand tu fais dans l'usine à gaz avec ou sans Agile, avec ou sans POO, avec ou sans n'importe quoi, l'usine à gaz reste une usine à gaz!!!

[Edrixal]

On a beau multiplier les outils, les méthodes et autres procédures X ou Y, les statistiques restent les mêmes depuis le début du développement informatique: 1/3 des projets répondent aux objectifs, 1/3 des projets finissent à plus ou moins fonctionner avec plein d'objectifs non-tenus et 1/3 des projets sont tout simplement abandonnés car trop malades!

Quand tu fais dans l'usine à gaz avec ou sans Agile, avec ou sans POO, avec ou sans n'importe quoi, l'usine à gaz reste une usine à gaz!!!

Justement, la problématique soulevé ici c'est de dire qu'il est plus compliqué en POO de ne pas finir par faire une usine à gaz.

[Anselme45]

Justement, la problématique soulevé ici c'est de dire qu'il est plus compliqué en POO de ne pas finir par faire une usine à gaz.

Faux!

Dans la grande majorité des cas, l'usine à gaz a pour origine la définition même des objectifs par le client! Il y a "usine à gaz" avant même qu'intervienne l'ombre d'un informaticien.

Alors ton POO se transforme en "Oh Oh Oh"

Et je ne parle même pas des changements d'objectifs qui interviennent tout au long de la phase de réalisation: Au départ, tu dois réaliser un avion long courrier et à la fin du projet on te demande où est le vélo pour unijambiste permettant de traverser Paris en équilibre sur la tête.

[mh-cbon]

Justement, la problématique soulevé ici c'est de dire qu'il est plus compliqué en POO de ne pas finir par faire une usine à gaz.

je soutiens votre propos. La question soulevée ici est bien l'efficience des outils à assurer la réussite des projets indépendamment des praticiens.

Tout l'article consiste à dire que les pratiques promulguez par la POO sont inefficace, voir malsaine, sur le long terme puisque l'apparente simplicité des concepts présentés mènent en réalité à produire des couches et des couches de complexité superflues, qui à leurs tours sont autant de facteurs amoindrissant le taux de réussite.

[mh-cbon]

Faux!

Dans la grande majorité des cas, l'usine à gaz a pour origine la définition même des objectifs par le client! Il y a "usine à gaz" avant même qu'intervienne l'ombre d'un informaticien.

Alors ton POO se transforme en "Oh Oh Oh"

Et je ne parle même pas des changements d'objectifs qui interviennent tout au long de la phase de réalisation: Au départ, tu dois réaliser un avion long courrier et à la fin du projet on te demande où est le vélo pour unijambiste permettant de traverser Paris en équilibre sur la tête.

on essaie de parler de l'impact des théories de programmation, pas de gestion de projets... peut on rester sur le sujet ? Les projects managers ont d'autres problèmes à gérer qui ne sont pas les nôtres.

[Neckara]

Qu'est-ce que je peux bien faire ce qu'un random "ingénieur informatique" peut penser ?
D'autant plus ici, un forum fréquenté par nombre d'ingénieurs informatiques ? Quelle légitimité ou compétence aurait cette personne vis à vis des membres déjà présents sur ce forum ?

[valtena]

Mouais, déjà la POO, c'est pas tout héritage. C'est aussi la composition avant l'héritage. L’héritage n'est là que dans des cas de spécialisation. C'est, à mon avis, une des bases que beaucoup oublient. Une base qui simplifie beaucoup le code POO.

Et si dans le monde réel, il y a de l'héritage, par exemple entre une race est une spécialisation d'une espèce. Quand à l'exemple de l'ADN, bien sûr que non le parent n'a pas d'impact sur l'enfant, c'est deux instances de la même classe ! La programmation fonctionnelle n'évitera pas les erreurs de modélisation. J'ai déjà récupéré des projets PF totalement impossible à faire évoluer (dans des coûts raisonnables) à cause de ça.

Quand à l'argument "sans outil c'est difficile", bha dans ce cas, les vis, les boulons, le béton, les voitures et tant d'autres outils sont nul, car ils faut des outils.

Non, pour moi, pour le problème vient vraiment pas des paradigmes. Ils viennent de :
- l’indécision du client. Qui n'est pas totalement réductible
- la manière dont on note la productivité des devs. J'ai l'impression qu'on privilégie trop souvent un dev qui sort beaucoup de code (quitte à avoir des effets de bord avec la mutabilité ou du code trop factorisé ou mal découpé), plutôt qu'un dev prendra soin de faire un maintenable et évolutif.

Je pense que pour ce deuxième point changera petit à petit. Notamment parce que les projets sont de plus en plus "vivant"( modifier et mis en prod tout le temps) et de plus en plus gros

[Jiji66]

La programmation Object a officiellement pour but de :
1) Créer du code autonome avec des interfaces d'interactions aux propriétés bien définies.
2) Faciliter la réutilisation du code entre autre à travers l’héritage.
3) Circonscrire les "bugs" au niveau de l'objet par l'encapsulation, ce qui facilite la correction et fait bénéficier les modifications a tout autre code qui utilise l'objet en question.
4) Obliger a définir en amont le projet avant de l'implémenter.... (c'est le plus dur)

Le polymorphisme ou la surcharge sont des facilités qui facilitent la propagation des "bugs" ...

C'est mon avis.

[mh-cbon]

Quand à l'argument "sans outil c'est difficile", bha dans ce cas, les vis, les boulons, le béton, les voitures et tant d'autres outils sont nul, car ils faut des outils.

ça tombe bien pour moi que vous parliez de clou et de vis, ça me permet de poster ceci, qui démontrera avec aisance que la méthode choisie initialement n'est pas une fatalité et peut avoir d'énormes conséquences pour le cycle de vie du produit.

[mh-cbon]

Qu'est-ce que je peux bien faire ce qu'un random "ingénieur informatique" peut penser ?
D'autant plus ici, un forum fréquenté par nombre d'ingénieurs informatiques ? Quelle légitimité ou compétence aurait cette personne vis à vis des membres déjà présents sur ce forum ?

on peut prendre les mêmes arguments, vous l'appliquez, et vous demandez par quel truchement vous commentez... ça ne mène à rien.

Personne ici ne peut présumer de la compétence d'un autre, à moins que celui ci fasse l'effort d'appuyer son propos d'un argument sur lequel chacun peut se faire juge. Pour moi vous êtes tout aussi random que le bloggeur, sans animosité, juste un fait.

Ce que vous faites là, au mieux, c'est du déni, au pire, de l'obscurantisme.

bref. restons en à râler après les PM, les clients etc.

[Neckara]

on peut prendre les mêmes arguments, vous l'appliquez, et vous demandez par quel truchement vous commentez... ça ne mène à rien.

Personne ici ne peut présumer de la compétence d'un autre, à moins que celui ci fasse l'effort d'appuyer son propos d'un argument sur lequel chacun peut se faire juge. Pour moi vous êtes tout aussi random que le bloggeur, sans animosité, juste un fait.

Sauf qu'en l’occurrence mon message est un post de forum, pas une actualité.

Et que je saches, à chaque fois qu'un membre poste un message sur un forum, on ne publie pas une actualité "d'après un ingénieur en informatique", "d'après un chercheur en informatique", ou autre.
Vu la masse d'ingénieur en informatique dans le monde, on pourra toujours en trouver deux qui diront deux choses totalement opposé, cela n'a donc guère de sens.
D'autant plus qu'on peut y ressentir un léger argument d'autorité, alors même qu'une bonne parti du publique a le même statu d'ingénieur informatique...

C'est tout aussi ridicule que de dire "les vaccins causent l'autisme, d'après un médecin". On s'en fout de ce que ce médecin particulier peut penser, et il ne va certainement pas faire autorité en la matière, d'autant plus si cela est posté sur un forum de médecins. Qu'on me dise "d'après une étude", "d'après l'académie des sciences de médecine", "d'après l'OMS", pourquoi pas. Ou alors de lancer un débat, mais partir au prétexte qu'une personne random a fait un billet de blog où il exprime son avis subjectif, c'est tout de même un peu osé.


C'est quand même assez culotté d'essayer d'user d'un pseudo argument d'autorité auprès d'un publique qui a tout autant de légitimité que lui, et peut-être même plus pour certains membres.

Ce que vous faites là, au mieux, c'est du déni, au pire, de l'obscurantisme.

???

[Lcf.vs]

Pour moi, le concept de classes est une phase très intéressante, pour des développeurs débutants, justement pour être initié à pas mal de concepts mais je ne fais plus de POO à base de classes, l'héritage peut avoir bien des visages et donc différentes utilités.

Je fais mon OO (en JS), à base d'objets-modèles immuables que je dérive, c'est un point que je trouve un point particulièrement intéressant, dans les propos de l'auteur, qui simplifie vraiment une codebase : l'immuabilité des objets.

Après, que ce soit fait à base de classes ou non, ça ne change pas grand-chose... cela n'engage que moi mais les classes sont juste une couche superflue.


EDIT : Pour les curieux, dérivant mes objets, les uns des autres, via un héritage par prototype, chacun de mes objets conserve un "historique" de dérivation, c'est hyper pratique pour plein d'usages.

[rheracles]

Vaste sujet, qui concerne une bonne partie ma vie, ayant appris seul à programmer sans objets à l'adolescence, puis ayant été obligé de me mettre à l'objet au début de ma vie pro.

C'est aussi un sujet quasi philosophique. L'orienté objet ressemble beaucoup à l'ontologie d'Aristote (philosophe réaliste, de "res", mot latin signifiant objet): substance et accidents, genre et espèce, ...

Je relève déjà deux erreurs dans l'article, ou disons deux arguments traités un peu trop rapidement...

1) "la programmation orientée objet dévie l’attention des développeurs de ce qui doit la retenir : la résolution des problèmes"

Encore faut-il que le problème soit posé, et bien posé, et bien intégré par le développeur. Le fait de bien définir les concepts et leur propriétés est crucial pour bien poser un problème. Avant de voir les fonctions, les actions, les opérations, etc... il faut poser les choses qui sont, décrire le réel statique. Et pour ça l'objet est fort !
Rien ne sert de décrire une recette de cuisine sans recenser précisément les ingrédients et ustensiles avant...
Un problème bien posé est déjà à moitié résolu. Un problème mal posé ne sera jamais résolu.

2) "Vous n'héritez pas des comportements de vos parents"

L'héritage génétique et l'héritage en orienté objet sont deux choses bien différentes, qu'il n'est pas du tout pertinent de comparer, bien au contraire. Dans l'orienté objet, il vaut mieux employer le terme de spécialisation / généralisation, beaucoup moins trompeur.

[micka132]

Qu'on me dise "d'après une étude", "d'après l'académie des sciences de médecine", "d'après l'OMS", pourquoi pas.

En même temps tes exemples ne font que multiplier le nombre d'auteur par 2 ou 3.
Après étant sur la partie du forum "Débats sur le développement", c'est un bon post de blog pour lancer un débat. Pourquoi faudrait-il y voir une forme d'autorité?

[PomFritz]

Ces discussions devraient faire réléchir ceux qui pensent qu'il s'agit juste de "pisser" du code pour faire ci-ou-ça. Quand je vois comment l'expérience et la formation continue sont mal récompensés dans la branche. Il faut savoir choisir ses outils pour chaque tâche, mais quand on bricole on prend ce qu'on a sous la main.

[mh-cbon]

Sauf qu'en l’occurrence mon message est un post de forum, pas une actualité.

Et que je saches, à chaque fois qu'un membre poste un message sur un forum, on ne publie pas une actualité "d'après un ingénieur en informatique", "d'après un chercheur en informatique", ou autre.
Vu la masse d'ingénieur en informatique dans le monde, on pourra toujours en trouver deux qui diront deux choses totalement opposé, cela n'a donc guère de sens.
D'autant plus qu'on peut y ressentir un léger argument d'autorité, alors même qu'une bonne parti du publique a le même statu d'ingénieur informatique...

C'est tout aussi ridicule que de dire "les vaccins causent l'autisme, d'après un médecin". On s'en fout de ce que ce médecin particulier peut penser, et il ne va certainement pas faire autorité en la matière, d'autant plus si cela est posté sur un forum de médecins. Qu'on me dise "d'après une étude", "d'après l'académie des sciences de médecine", "d'après l'OMS", pourquoi pas. Ou alors de lancer un débat, mais partir au prétexte qu'une personne random a fait un billet de blog où il exprime son avis subjectif, c'est tout de même un peu osé.


C'est quand même assez culotté d'essayer d'user d'un pseudo argument d'autorité auprès d'un publique qui a tout autant de légitimité que lui, et peut-être même plus pour certains membres.



???

vous reprochez à l'auteur de l’article de s'être fait publier ici, alors que ce n'était pas de son fait.
vous réduisez la recherche en théorie de programmation à un mec qui poste un blog, alors que bon, y'en à quand même un plus sous le tapis. A commencer par toute la communauté FP. Ou juste l'autre mec qui a fait une vidéo sur le même sujet que j'ai moi même posté. Dans tous les cas ce n'est pas réduit à cette personne.
vous semblez vous prétendre d'un droit supérieur à commenter.
vous prétextez à des arguments d'autorité tout en proclamant qu'il faudrait attendre qu'une 'autorité compétente' donne son aval pour que nous puissions débattre.
Soit dit en passant, c'est un fait, que le calcul lambda à plusieurs dizaines d'années de recherches d'avance sur la POO.
Par ailleurs, lorsque vous dite "une étude", voilà une recherche qui a changé le monde, publié par un seul homme http://www-m3.ma.tum.de/foswiki/pub/...e/dijkstra.pdf

parce qu'en fait votre propos consiste à dire "si ça ne vient pas d'une autorité 'compétente' et 'collégiale', alors ce n'est même pas la peine d'en discuter".

c'est la blague de lire ça de la part de quelqu'un qui fait des billets pour "bien débattre".
Car non content de promouvoir une vision étriqué d'un monde qui serait faits d'autorités de penser et de suiveurs, vous prétendez même apprendre aux gens à réfléchir par eux mêmes, puisque c'est l'activité principal d'un débat bien ordonné.

Je nage en plein délire ; )

Pour finir, au sujet de votre diatribe sur la médecine, j'invite le lecteur à se renseigner sur l'histoire de la pénicilline. Un exemple parmit d'autres hein.

Finalement, je maintiens mon propos, en vous contentant d'attaque ad hominem au sujet de l'auteur initial (même si bon je m'interroge à savoir si c'est à lui ou à Patrick Riuz que vous en voulez), vous empêchez le débat. C'est de l'obscurantisme.