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 ?

[Pyramidev]

bein quid de la vidéo de 45 min que j'ai apporté d'un mec qui présente les mêmes arguments sans pour autant travailler pour cette entreprise.

Je viens de revoir la vidéo de 45 minutes (que j'avais déjà vue il y a longtemps) de Brian Will et les arguments ne sont généralement pas les mêmes que ceux de Ilya Suzdalnitski, l'auteur de l'article qui est l'objet de ce fil.
Brian Will pense qu'il faut revenir au bête paradigme procédural alors que Ilya Suzdalnitski pense qu'il faut faire de la programmation fonctionnelle.
Le plus gros point commun entre leurs argumentations est que les deux affirment que Java a eu du succès pour d'autres raisons que la POO.
Mais les arguments sont globalement différents : Brian Will passe la plus grande partie du temps à argumenter contre l'encapsulation alors que Ilya Suzdalnitski passe la plus grande partie de son temps à argumenter contre les états muables partagés.

[el_slapper]

J'ai toujours été une bête étrange, affectée à des tâches bêtement procédurales(auxquelles j'ajoutais souvent une dose subtile, mais limitée, de fonctionnel - limitée parce-que je connaissais le genre de gugusse qui passerait après moi, et c'était à lui qu'il fallait penser), alors qu'autour de moi la POO fleurissait de partout.

Je ne peux dont pas juger des a-priori théoriques qui fleurissent partout dans ce fil. Le peu de POO que j'ai fait ne me donne pas autorité à ce sujet. Donc je vais me contenter de faire quelques réflexions vu de loin. Basées sur ma seule expérience(qui n'est donc pas un échantillon statistique valide).

En premier, à chaque fois qu'on a été mis en concurrence avec de l'objet(souvent du JAVA), nous avons gagné. Soit nous étions moins chers au développement(du genre moitié moins cher au devis, et moitié moins de dépassements du devis), soit le méga projet JAVA moderne qui devait nous remplacer avait des performances inacceptables (20 semaines pour faire tourner 100% de la volumétrie de prod sur un seul des innombrables batches de fin d'année, ouate de phoque?).

En second, nous étions bien plus faciles à déployer. Je ne dis pas que nous faisions face à de l'objet bien conçu(vous allez sans doute me dire que non, et il est bien possible que vous ayez raison). Je dis juste qu'en procédural, là ou je suis passé, on a pas besoin de tout recompiler à chaque fois qu'on modifie un pet de mouche. A certains endroits, je livrais en prod en 4 minutes, là ou les gens du JAVA en avaient pour une semaine de casse-tête à l'"intégration"(quoi que ça veuille dire) pour faire leur build. Quand je voulais modifier un composant, ben, je travaillais sur ce composant, sans me soucier du reste, juste de ses entrées sorties, alors que les collègues du JAVA étaient obligés de se farcir l'intégralité du projet sur leur machine pour arriver à bosser. Ce qui explique probablement au moins partiellement leurs temps de développements rajoutés.

la différence fondamentale que je perçois entre l'objet et le procédural, c'est qu'en objet, on couple fortement la définition de données et le code qui s'applique aux données. Exemple. En bancaire, on peut avoir une structure de données pour le compte en banque, avec le numéro, l'agence, le numéro du client, le solde, et quelques autres données. En procédural, on aura juste une structure vierge(qui ne serait autre qu'une classe avec juste des getters-setters, au final), et tout le code sera ailleurs. Par exemple, on aura, ailleurs, un fichier qui contient la fonction qui calcule la clef RIB. En objet, cette fonction sera plus ou moins une méthode appartenant à la classe. Ce qui est intellectuellement bien plus élégant : là ou est défini le RIB est calculé sa clef.

Dit autrement, le jour ou on modifie le calcul de la clef RIB(par exemple pour des raisons de performances, le fonctionnel ne change pas souvent), en procédural, on charge le module, on le modifie, on le teste, on le livre. Seul. Basta. En objet, il faut recompiler tout le projet. Parce-que tous les composants utilisent la classe "compte"(en bancaire, c'est un peu la base...). Ce qui rend les manipulations bien plus lourdes.

J'ai bien conscience que ce ne sont que des exemples, et qu'il existe probablement plein de bonnes pratiques que les vrais bons informaticiens POO utilisent pour éviter ce genre d'horreurs. N'en reste pas moins qu'avec la qualité moyenne de l'informaticien moyen, l'objet me semble une mauvaise idée, parce-qu’il pose trop de problèmes lorsqu'il est mal utilisé. Et il sera mal utilisé. Comme le procédural, d'ailleurs, mais pas avec des conséquences aussi massives.

(oui, je m'attends à un flot d'injures. Acceptées par avance)

[Neckara]

Dit autrement, le jour ou on modifie le calcul de la clef RIB(par exemple pour des raisons de performances, le fonctionnel ne change pas souvent), en procédural, on charge le module, on le modifie, on le teste, on le livre. Seul. Basta. En objet, il faut recompiler tout le projet. Parce-que tous les composants utilisent la classe "compte"(en bancaire, c'est un peu la base...). Ce qui rend les manipulations bien plus lourdes.

Euh non... il n'y a pas besoin de recompiler tout le projet et heureusement.

Imaginez qu'il faille recompiler la moindre application au moindre changement d'une bibliothèque partagée (.so en C++ / .jar en Java ?), ce serait invivable.
Tant que l'API/ABI ne change pas, il n'y a pas besoin de recompiler, juste de mettre à jour les .so / .jar (?).

Au pire, refaire l'édition des liens, mais cela vaut pour tous les langages compilés.


À ne pas confondre avec les templates du C++ où là, oui, il faudra recompiler tous les fichier utilisant le template modifié.
Quoiqu'encore, en fonction du besoin précis, on peut trouver des solutions.

N'en reste pas moins qu'avec la qualité moyenne de l'informaticien moyen, l'objet me semble une mauvaise idée, parce-qu’il pose trop de problèmes lorsqu'il est mal utilisé. Et il sera mal utilisé. Comme le procédural, d'ailleurs, mais pas avec des conséquences aussi massives.

Avec le procédural, tu peux te retrouver avec de la duplication de code en c/c, des fonctions réparties à droite et à gauche, du code mort caché dans un des fichiers, des structures modifiées de façon incohérentes par des fonctions qui ne devraient pas y toucher, etc.

Il me semble donc difficile d'affirmer que les erreurs en POO seraient plus "graves" qu'en procédural.

[el_slapper]

Euh non... il n'y a pas besoin de recompiler tout le projet et heureusement.

Je parle de ce que j'ai vu, et par définition, c'est fort limité. ravi d'apprendre qu'il y a des alternatives.

Imaginez qu'il faille recompiler la moindre application au moindre changement d'une bibliothèque partagée (.so en C++ / .jar en Java ?), ce serait invivable.
Tant que l'API/ABI ne change pas, il n'y a pas besoin de recompiler, juste de mettre à jour les .so / .jar (?).

Tiens, on a une appli secondaire en java, là ou je suis. Un truc dont on va se débarrasser, d'ailleurs, mais qui pour l'instant survit(malheureusement, les clients en sont contents...). On livre un seul .war. J'en déduis que le programmeur compile tout à chaque nouvelle livraison. Ce n'est pas méchant parceque ça devient rare, mais c'est un bloc de 50 Mo à chaque fois. Pour un gadget additionnel, pas pour notre produit principal. Après, si tu me dis que c'est une mauvaise pratique, OK. Dans ce cas, c'est juste une mauvaise pratique que j'ai vu partout ou je suis passé(j'ai pu ne pas avoir de chance).

Au pire, refaire l'édition des liens, mais cela vaut pour tous les langages compilés.

oui, ça vaut pour tout, les liens. Mais quelle est la taille moyenne de ta dll? Moi, je livrais des composants unitaires de quelques ko maximum. Tous indépendants.

Avec le procédural, tu peux te retrouver avec de la duplication de code en c/c, des fonctions réparties à droite et à gauche, du code mort caché dans un des fichiers, des structures modifiées de façon incohérentes par des fonctions qui ne devraient pas y toucher, etc.

Jamais eu de soucis avec les structures(et pourtant j'en ai vu, des horreurs), par contre, tout le reste est vrai(et le plus dangereux me semble être la duplication de code, bien plus facile en objet, enfin, de mon expérience limitée).

Il me semble donc difficile d'affirmer que les erreurs en POO seraient plus "graves" qu'en procédural.

Encore une fois, je ne regarde pas la cuisine en interne, je n'ai pas le niveau(en POO) pour ça. Je regarde vu de loin. Quand COBOL fait un devis de 120 jours, JAVA un devis de 250 jours, que COBOL dépasse de 10%, et JAVA de 20%, tu te poses des questions. Surtout quand tu te retrouves à voir ça plusieurs fois de suite, dans plusieurs équipes différentes, dans plusieurs boites différentes, avec ton code COBOL(plein de redites, de code mort caché, et de procédures un peu perdues à droite à gauche; je dis procédures parce qu’il n'y a pas vraiment de fonctions en COBOL) bien plus performant(mesuré 20 fois plus rapide) et maintenable(mesuré 2 fois plus rapide) que du JAVA soi-disant suivant les normes les plus modernes.

Les raisons exactes, je ne les connais pas. Peut-être est-ce juste JAVA. Peut-être les cobolistes étaient-ils bien meilleurs que les javaistes dans mon contexte(j'en doute fort, et même si c'était vrai, ça serait une raison suffisante pour préférer COBOL). Mais ça me fait douter de l'objet plus propre, plus maintenable.

Pas forcément vrai : c'est tout l'intérêt de l'injection de dépendance : je ne vais pas te résumer tout ça car pas le temps et l'espace mais regarde un Framework comme Prism (il y a pléthore de framework du genre) en C#.
Si l'architecture d'une solution est bien établie, ton argument ne tient pas

Donc il faut un framework objet complet pour imiter ce que fait une bête fonction/procédure?

Avec l'exemple que tu donnes : j'ai un service du type IRibKeyGenerator avec dedans une méthode qui me retourne la clé. C'est tout. Et partout dans mon programme, je vais utiliser cette interface et demander au framework d'injection de dépendance de me donner une implémentation de cette interface. L'implémentation est dans une micro DLL qui est injecté au runtime du coup si je switch la micro DLL, on verra que du feu. (edit : évidemment il faut recompiler la micro DLL)

ça règle le problème de la livraison(en admettant qu'on aie les outillages pour faire tout ça de manière industrielle, comme le souligne Nebulix, ça n'est pas rien), mais pas celui de la performance. Combien ça coûte en overhead, tous ces trucs là? Si un appel passe par le framework, ben, il exécute du code framework, pas que du code fonctionnel. donc c'est coûteux en temps d’exécution. ce qui est un problème - ou pas, suivant les contextes, mais il y a des contextes ou c'est un problème.

Encore une fois, je ne dis pas "procédural bieeeeen, objet maaaaaaal", l'objet permet déjà de limiter fortement les redites, et c'est un avantage dont on aura du mal à sous-estimer les bienfaits. Je ne suis juste pas sur que le discours associé, qui veut que ça soit le graal, soit toujours pertinent. Je garde cette impression, spécialement en lisant cette réponse, qu'on ajoute de hauts niveaux de complexités qui peuvent fortement obérer l'avantage pourtant évident à limiter les redites.

[Kikuts]

le jour ou on modifie le calcul de la clef RIB, en procédural, on charge le module, on le modifie, on le teste, on le livre. Seul. Basta. En objet, il faut recompiler tout le projet. Parce-que tous les composants utilisent la classe "compte"(en bancaire, c'est un peu la base...). Ce qui rend les manipulations bien plus lourdes.

Pas forcément vrai : c'est tout l'intérêt de l'injection de dépendance : je ne vais pas te résumer tout ça car pas le temps et l'espace mais regarde un Framework comme Prism (il y a pléthore de framework du genre) en C#.
Si l'architecture d'une solution est bien établie, ton argument ne tient pas

Avec l'exemple que tu donnes : j'ai un service du type IRibKeyGenerator avec dedans une méthode qui me retourne la clé. C'est tout. Et partout dans mon programme, je vais utiliser cette interface et demander au framework d'injection de dépendance de me donner une implémentation de cette interface. L'implémentation est dans une micro DLL qui est injecté au runtime du coup si je switch la micro DLL, on verra que du feu. (edit : évidemment il faut recompiler la micro DLL)

[Nebulix]

... demander au framework d'injection de dépendance de me donner une implémentation de cette interface. L'implémentation est dans une micro DLL qui est injecté au runtime du coup si je switch la micro DLL ...

Au secours !
Il me semble ( comme el_slapper ) qu'appeler une fonction ...

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

[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]

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.

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

[Mat.M]

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.

la notion d'abstraction je dirai que c'est à 95% le problème des projets informatiques.
C.a.d que d'une personne à l'autre on ne conçoit pas forcément les choses de manière identique.

Ensuite le danger des objets mutables c'est de de définir des objets indéfinis
Ca.d que si on modifie les attributs d'une classe d'objet on risque de tourner en rond plus qu'autre chose

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.

bonjour je crois que je l'ai écris sur ce forum le risque avec la POO c'est de faire du code "lasagne" c.a.d qu'on empile des codes d'objet contrairement au code spaghetti où le code part dans tous les sens avec un langage procédural
Ensuite par principe lorsque l'on conçoit une classe c'est dans un mécanisme d'abstraction et l'abstraction de l'abstraction cela finit par mener à l'ensemble vide

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

[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

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

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

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