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 
Envoyé par Golgotha
