La programmation orientée objet pour les nuls (et les cheffs)

Cela faisait des années que je n’avais pas entendu parler de ce concept fumeux de « Programmation orientée objet ». C’est l’ami Disp qui l’évoque dans son blog, aujourd’hui.  Amis informaticiens, ne ronchonnez pas ! Je sais que vous utilisez ce truc au quotidien. Je ne dénigre pas les développeurs mais uniquement leurs chefs.

Disp pousse un cri : « La POO n’est pas morte ! »

Néanmoins, je n’oublie pas qu’une partie de mes lecteurs sont des lascars qui ne connaissent rien à la programmation orientée objet. Je vais leur expliquer. Vous connaissez Candy Crush ? A l’écran, on va dire qu’on a des bonbons de différentes couleurs, disons des rouges des bleus, des jaunes et des verts, pour simplifier. Chaque bonbon a des caractéristiques communes : descendre d’un cran s’il n’y a personne en dessous, pouvoir être déplacés d’un cran, occuper la place de celui qui vient prendre sa propre place, être détruit dans certaines conditions (si les voisins sont identiques par exemple). On va dire que chaque bonbon est un objet. Tous les bonbons ont les caractéristiques que je viens de citer. Mais les bonbons de chaque couleur ont des caractéristiques différentes. Les bonbons jaunes rigolent quand on leur caresse les nichons, les rouges chantent la marseillaise en breton, les bleus boivent de la bière quand on a les yeux tournés et les verts racontent des conneries dans leurs blogs. Parmi ses caractéristiques différentes, n’oublions pas l’essentiel : la couleur et le fait qu’ils soient d’une même famille pour être détruits quand ils sont alignés.

Le mec  qui développe, il va définir ce qu’est l’objet bonbon avec les caractéristiques  principales, puis définir les bonbons des quatre couleurs qui « hériteront » des caractéristiques décrites dans les bonbons et avoir les caractéristiques propres. Ainsi, si vous avez trente bonbons à l’écran, le développeur n’a pas… développé trente bonbons mais un seul objet et ses quatre petits frères.

Normalement, à ce stade, vous avez tout compris de la programmation orientée objet. Je vais quand même continuer au cas où vous seriez très con.

Candy Crush est composé d’un certain nombre de tableaux, avec chacun un objectif (dépasser un certain nombre de points, casser toute la glace,…). Les tableaux ont ceci en commun : ils ont une ou plusieurs grilles dans lesquelles on pourra mettre les bonbons. Dans chaque grille, nous avons des cases, à peu près toutes identiques, d’un point de vue du développeur : une case peut contenir un bonbon ou être bouchée par du chocolat. On va donc définir un objet case, avec un attribut : ce qu’elle contient. Soit du chocolat, soit un bonbon. On va ensuite définir l’objet grille, qui sera composé d’un certain nombre de cases, définies sur la base de l’objet case.

Le développeur pourra ainsi se baser sur l’objet « grille » pour définir ses différents tableaux. Et tant qu’à faire vous créez des objets « tableau ».

Voila, c’est tout ! Ou presque, il faudra ajouter quelques milliers d’heures de travail pour faire fonctionner ce qu’un blogueur a écrit avant d’aller au bistro.

J’arrête mes explications. Si vous n’avez rien compris, vous pouvez chercher « programmation orientée objet » dans Google. Si vous n’avez pas de bol, vous tomberez sur le présent billet.

Mise en pratique

Vous allez donc réunir une équipe de développeurs. Celui pour l’objet bonbon, ceux pour chacun des bonbons de couleur, celui pour la case, celui pour la grille, quelques-uns pour les tableaux. Vous êtes le chef : vous pourrez aller boire une bière pendant qu’ils travaillent. Mais avant, il faudra leur dire précisément quoi faire et comment utiliser les objets définis par les autres.

C’est tout con, hein ?,  vu comme ça.

A notons qu’après avoir créé les objets « bonbon », nous pourrions les utiliser pour créer d’autres jeux, comme Jelly Mania qui ressemble à Candy Crush mais avec des yaourts. Il faudrait donc créer un « objet objet » destiné à occuper des cases dans les jeux. Les objets bonbon de Candy Crush et les objets yaourt de Jelly Mania hériteraient de leurs caractéristiques.

Hop !

Et sans objet ?

Imaginions que le dieu de l’informatique n’ait pas inventé la programmation orientée objet et que nous devions développer Candy Crush pour gagner beaucoup de sous pour payer beaucoup de bière. Comment ferions-nous ? Nous ne pourrions pas définir des objets bonbon, des objets bonbon vert, rouge, bleu et jaune, des objets case, des objets grilles et des objet tableau. Nous serions bien emmerdés et resterions à nous caresser les couilles en regardant l’écran.

L’objet est utile. J’espère que j’ai rassuré Disp.

Nous avancerions quand même. Nous n’allons quand même pas programmer chaque bonbon de chaque case de chaque grille indépendamment ! Nous créerions donc un certain nombre de fonctions pour gérer tout ça, ça serait vachement lourd et compliqué.

Mais, au final, nous n’aurions rien fait d’autre que de créer des objets, finalement… Nous aurions des bonbons de différentes couleurs, des grilles,…  Mais ce ne sont pas milliers d’heures que nous y aurions consacré mais des dizaines de milliers.

La programmation orientée objet est donc très utile. C’est une bonne méthode de programmation. Mais ce n’est qu’une méthode de programmation qui se découle en langages de programmation, les plus connus actuellement sont probablement PHP, Java, C++,…

Avec eux, on peut créer facilement des objets bonbon.

De la critique utile de la programmation orientée objet

Tout  d’abord et pour commencer, elle n’est pas adaptée pour tout. Plus précisément, elle n’est pas l’idéale pour tout. L’intérêt est : qui peut le plus peut le moins. Beaucoup de développeurs utilisent des langages dits « objet » mais c’est donner de la confiture aux cochons. Les amateurs de confitures doivent être formés et ça coûte des sous. En fait, dans beaucoup d’applications, les objets sont uniques. Par exemple, si vous faites une version de démonstration de Candy Crush avec un seul tableau, ce n’est pas la peine de créer un objet « tableau » ni même un objet « grille ». Dans le temps, on se passait très bien des objets. Du moins, on en faisait comme Monsieur Jourdain. Il faisait des objets sans le savoir.

Ensuite et pour poursuivre, si elle n’est pas adaptée pour tout, elle induit en erreur parce que des développeurs sobres pourraient dire : « tiens je vais faire de l’objet », or il n’en fait pas. Il fait de l’informatique traditionnelle. Cela génère des bugs et autres dysfonctionnements. C’est mal.

Enfin et pour terminer, il faut faire un peu d’histoire.

Un peu d’histoire

La programmation orientée objet est relativement ancienne (Wikipedia est ton ami) mais elle est devenue à la mode dans les années 80. A mon expérience personnelle, je pourrais dater cela de 86 ou 87. On ne parlait plus que de ça. Les entreprises voulaient découvrir ce qui serait la programmation du futur.

C’était très rigolo car nous avions des gens avec de cravates et du poil dans les oreilles, généralement on appelle ça des directeurs et des consultants, qui parlaient objet sans absolument savoir de quoi ils parlaient, confondant une méthode de programmation avec une méthode d’analyse. C’est dommage, Candy Crush n’existait pas à l’époque, mais ils faisaient très sérieusement ce que je faisais en déconnant ! Oui ! C’est génial, on va créer un objet bonbon, puis un bonbon vert et un bonbon rouge. Ou un yaourt, je ne sais plus, n’essayez pas de m’embrouiller.

Ils ne savaient absolument pas de quoi je parlais. Je suis prêt à parier, d’ailleurs, qu’une partie des développeurs qui font des objets aujourd’hui ne savent même pas quelles sont les conséquences : allocation de mémoire et tout ça.

Dans les années suivantes, ils ont obligé leurs équipe à faire de la programmation orientée objet mais en insistant sur l’aspect « objet » parce que ça fait bien, pas sur le langage de programmation lui-même, vous savez, le truc qui permet d’écrire « class bonbon » pour créer l’objet bonbon. Ces valeureuses équipes se sont retrouvées à réécrire leurs logiciels en remplaçant les fonctions par des classes parce qu’ils ne savaient pas quoi faire d’autres, leur chef leur a dit de faire des objets. Je n’abuse pas, y compris parmi les paradoxes du présent paragraphe. C’était un bordel monstre.

Je pourrais vous raconter quelques anecdotes mais ce billet est trop long, d’autant qu’à peu près à la même époque, il y a eu une autre révolution : la généralisation de Windows. Passant d’un environnement « mono tâche » en MS-DOS, les boites se sont trouvées à passés à Windows et en ont profité pour faire le passage à l’objet (ce qui était une bonne idée) dans un joyeux bordel, sans penser réellement à l’avenir de leurs applications…

Mais pendant toutes cette phase, les « maîtrises d’ouvrage » (la partie des informaticiens qui ne font pas d’informatique mais font la relation entre les utilisateurs et les développeurs) ne sont pas restés à glander. Ils ont voulu créer « la conception orientée objet » et tout est parti en couilles.

Mais c’est une autre histoire.