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.