Certains éminents spécialistes et renommés mais sans peur et sans reproche s'évertuent à sonner le glas de l'objet.
Que nenni !
La programmation orientée objet est une technique de programmation célèbre qui existe depuis des années maintenant. De nombreux langages sont basés sur ses principes comme le C++, PHP, Java et Python pour ne citer qu'eux.
Certes, la programmation orientée objet, que nous abrègerons POO, n'est pas le Saint Graal : elle ne va pas améliorer subitement la qualité d'un comme par magie. En revanche, elle va aider le développeur à mieux organiser votre code, à le préparer à de futures évolutions et à rendre certaines portions réutilisables pour gagner en temps et en clarté.
C'est pour cela que les développeurs professionnels l'utilisent dans la plupart de leurs projets.
Mais le débat va plus loin que cela. A l'heure où le Ministre de l'Education Nationale décide d'intégrer l'apprentissage de la programmation aux cours délivrés à nos enfants à l'Ecole Primaire et quand on voit que même les deux programmes expérimentaux les plus avancés dans le domaine que sont Scratch du Medialab ou Etoys sont abstraitement objets, le sujet devient stratégique.
Il faut que nos enfants apprennent à penser objet, c'est à dire abstrait. C'est critique pour que ce pays dégage des capacités d'innovation en matière technologique. L’abstraction en tant que processus qui consiste à représenter des objets qui appartiennent au monde réel dans le monde du programme que l’on écrit consiste essentiellement à extraire des variables pertinentes, attachées aux objets que l’on souhaite manipuler, et à les placer dans un modèle informatique convenable.
Educateurs de France, enseignez l'abstraction, l'objet et l'héritage pour former nos champions de demain.
Ceci mériterait une réponse détaillée mais je ne sais pas si je vais avoir le temps.
RépondreSupprimerTout d'abord tu me lances une grave agression (smiley) dès l'introduction. Je n'ai pas sonné le glas de l'objet, j'ai simplement répondu à une de tes remarques sur l'héritage.
Maintenant, dans le détail, on a beaucoup parlé de POO dans la fin des années 80 et dans les années 90 en confondant deux choses : la méthode d'analyse et la méthode de programmation. Ce n'est pas très grave mais ça a introduit des mauvais choix politiques pour les entreprises qui ont dépensé des sommes folles dans l'objet alors que les informaticiens rigolaient bêtement : ils ne faisaient que passer de C à C++. Ils rigolaient mais ils ont fait des erreurs puisqu'ils ont commencé à tout considérer comme des objets, en faisant la démarche inverse : confondre la POO et la COO (Conception).
A cette époque, je bossais dans une boite qui développait des logiciels pour distributeurs de billets. Moi, je bossais en C à la maintenance d'une application mais la boite avait refondu son application principale pour passer en C++ (c'est quand même délirant : un conseil de direction a donné du budget pour réécrire une application en "objet" sans même savoir ce que c'était...). Je développais aussi des utilitaires qui pouvaient s'interfacer avec toutes les applications de la boite. C'est en les testant que je me suis rendu compte du nombre de bug qu'ils faisaient avec leur truc orienté objet qui ne l'était qu'à moitié puisque le sujet ne le nécessitait pas.
On a érigé ce machin à la position de dieu vivant alors qu'au final ce n'était qu'une facilité pour les développeurs. Ces ânes se sont mis à faire des "new" dans tous les sens sans même se rendre compte de ce que ça faisait réellement, ils ont perdu toute relation avec la machine. Ce que tu appelles l'abstraction s'est transformé en catastrophe à cette époque... parce qu'elle faisait perdre toute rigueur au développeur, encore plus qu'avant.
Je vais me faire mousser un peu : comme ça me faisait chier de tester mes logiciels, je les développais parfaitement dès le premier coup, ce qui fait qu'ils n'avaient aucun bug. J'avais une énorme capacité de concentration et une rigueur incroyable... C'est une forme d'esprit que l'objet a tué. Les gens ne savaient plus ce qu'ils faisaient.
A noter que je critique bien cette période. Je ne fais plus de développement et les langages modernes sont entrés dans les moeurs...
Enfin, tu viens de nous pondre une belle théorie, digne d'un directeur de département (ce n'est pas une critique, je prépare les mêmes trucs pour ma hiérarchie, c'est même un peu mon métier, la vulgarisation et tout ça).
Comment peut-on dire qu'un objet est abstrait ? Mon dieu...
Je pense que tu as raison quand tu dis que les premiers projets en objet ont été des catastrophes. En fait, c'est parce qu'ils confiaient une programmation objet à des développeurs non objets que c'est devenu en partie une catastrophe. Cette période a été un peu n'importe quoi en informatique dans les boites privées. J'ai parfois l'impression que c'est la période équivalente que vivent les administrations centrales en ce moment avec tous les projets pharaoniques ratés genre paye de l'armée.
RépondreSupprimerMon boulot, c'est aussi de construire des pitchs. Comme toi et le blogage est une activité éducative pour apprendre à argumenter.
Un objet peut être abstrait notamment pour les objets connectés ou les objets enchantés. Si tu veux hardwariser les objets, il faut bien les dupliquer abstraitement. Non ?
Je vais en faire un billet mais je ne suis pas d'accord avec ton premier paragraphe. Les développeurs ne sont pas en cause. Ce sont les hiérarchies qui ont merdé en imposant un truc à la mode qui n'était qu'une évolution des méthodes mais en en faisant une révolution pour pouvoir communiquer.
SupprimerEn gros, on est passé du C au C++ en disant : on fait de l'objet. Et comme il fallait que ça se sache, on a théorisé le truc dans les dossiers d'analyse.
Je fais du logiciel pour distributeur de billets. Alors les lascars ont facilement trouvé des "objets" : l'imprimante, les cassettes à billet. C'était facile d'imaginer un objet "cassette" avec des héritages et tout ça... Mais c'était hors sujet.
Je pense que tu développes une théorie politique des projets informatiques. Remarque, cela a du sens, pourquoi pas. Je pense qu'un développeur traditionnel mode "Traitement et données" était à l'époque proprement incapable de passer à l'objet. C'est une question de méthode de pensée. La hiérarchie n'a pas appréhendé l'écart.
SupprimerOui, je fais bien une théorie politique... D'ailleurs, on est à peu près d'accord sur le reste, sauf sur la "méthode de pensée" : un langage informatique, ça s'apprend. Quand tu passes du C au C++ (je suis un ancien), ça s'apprend. Il faut quelques jours, c'est tout. Tu trouves de très bonnes explication rien qu'avec Google.
SupprimerTiens ! La première entrée (après Wikipedia) te montre ça de façon très claire.
Ce que je dis, c'est qu'il y a eu une marche forcée vers l'objet y compris pour des cas où cette méthode n'était pas adaptée.
Ce que je dis aussi, c'est qu'il faut former les jeunes PHP, C++ et autres Python, le concept d'objet viendra tout seul.
Ce que je dis, enfin, c'est que c'est un truc de développeur, de chef de projet,... et que ça n'a rien à faire au niveau d'une direction d'une boite.
La plupart des languages objets ont surtout su s'adapter à leur époque en piochant les bonnes idées d'autres languages et paradigmes de programmation (lambda/closure par exemple).
RépondreSupprimerDe trop nombreuses formations et projets ont transformés le principe d'héritage et les design patterns à la sauce Java en une solution à tout.
Sur de vrais projets, les trop nombreuses abstractions inutiles et l'héritage multiple font que l'on préfère largement travailler avec de la composition plutôt que de l'héritage.
En composant plutôt qu'en héritant, on peut plus facilement choisir les méthodes dont on a besoin et même partager des méthodes entre des objets qui à première vue n'ont pas grand chose à voir l'un avec l'autre.
La plupart des languages modernes vont d'ailleurs dans ce sens (Ruby ou Go pour ne citer que deux exemples).
oui, j'ai l'impression qu'il y a un consensus là dessus : http://blog.emmanueldeloget.com/index.php?post/2006/12/14/44-heritage-et-composition j'aimerais bien voir un cas concret de code composé vs hérité mais pas trop compliqué )))
SupprimerJ'ai tout lu ! Mais pas tout compris. L'introduction est à se plier de rire avec les questions métaphysiques que se pose l'auteur. De mon temps, quand on voulait réutiliser du code on créait une "fonction"...
SupprimerOui il est pas mal ce post ....
SupprimerIl ne vaut pas celui que je viens de faire.
Supprimer