17 juillet 2014

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.

11 commentaires:

  1. Je me sens un peu rassuré. Il est clair que l'on est passé en France à la POO sans penser à la conception. En France, cela a été un énorme bordel car la France, je voulais le rappeler a inventé la méthode Merise, qui est une méthode traditionnelle orientée MCD. Il fallait avant former les hommes à cravate en forme de larmes et à poils dans les oreilles à UML ou quelque chose d'équivalent. Il faudrait refaire l'historique des projets gâchés.

    Il faudrait aussi expliquer le concept de la composition dans ton post à opposer à l'héritage.

    RépondreSupprimer
    Réponses
    1. J'aurais beaucoup de critiques à faire à UML qu'on nous a imposé il y a quelques années mais qui n'est pas nécessairement adapté à tous les usages. Comme pour l'objet, on s'imagine que dans mon secteur, c'est très adapté alors qu'il n'en est rien pour différentes raisons (par exemple, sur nos machines nous utilisons des progiciels que nous paramétrons). L'UML a générés des coûts incroyables, d'une part par le coût de mise en œuvre (temps passé) et d'autre part parce qu'il a imposé des évolutions des processus et des développements informatiques pas nécessaires. Ou alors, c'est le contraire dans certains projets : les gens fuient UML parce que ça leur ferait ouvrir les yeux sur les merdes qu'ils ont conçues auparavant. Mon propos est paradoxal mais c'est ainsi.

      Par ailleurs, il faut laisser les méthodes aux informaticiens pas aux utilisateurs. Avec ça, ils se mêlent de ce qui ne les regarde pas. Dans le projet sur lequel je bosse, ils m'ont imposé la méthode que l'on doit utiliser pour historiser les opérations alors que le besoin est l'historisation. Donc ils nous font sortir de nos architectures techniques et applicatives. Je vais être obligé de faire remonter un point mineur à un conseil de direction alors qu'il devrait être du ressort d'un comité de pilotage, voire d'un "vulgaire" comité projet (voire un groupe de travail). Ça va coûter cher, déranger des patrons et fâcher des gens (comme j'ai raison, sur le fond comme sur la forme, ils vont se ridiculiser auprès de leur hiérarchie).

      Supprimer
    2. Ce sont tous des Harry Potter et des apprentis sorciers, et oui c'est énervant qu'ils ne laissent pas cela aux spécialistes. C'est un vrai sujet d'ailleurs en France que des néophytes se mettent à faire des choix technologiques. La vague digitale peut être en partie la cause de cela. En tout cas beau Post !

      Supprimer
  2. j'ai pratiqué Merise mais c'est plus un objet d'analyse et d'inventaire des données avant toute programmation

    RépondreSupprimer
    Réponses
    1. C'est surtout un truc totalement obsolète qui n'aurait jamais du exister. Ou presque.

      C'est le problème de toute méthode. Elle jamais adaptée à un truc complet. Ça fait que nous n'utilisons plus de méthodes dans les entreprises, de manière globale.

      Ce qui ne veut pas dire ne pas utiliser de normes. Ne pas confondre les deux, ce qu'on fait pourtant souvent. Ou confondre les méthodes et les architectures.

      Tu mets ta carte dans un automate pour retirer du pognon. Entre le moment où tu choisis le montant et le moment où la machine commence à préparer le pognon, il se passe moins d'une seconde. Pendant ce temps, on a appelé ta banque qui a vérifié ton compte, l'historique des retraits,... Tu penses bien qu'aucune méthode n'est adaptée pour ça concevoir cela.

      Supprimer
    2. moi j'étais dans la gestion et la paie du personnel
      Merise nous a bien aidé pour intégrer les attentes des utilisateurs au plus bas niveau

      Supprimer
    3. Gros sujets que les méthodes : sans parler du Manifeste Agile, du SCRUM etc

      Supprimer
    4. Oui. J'ai toujours eu la chance d'y échapper sauf dans "le deuxième tiers" de la précédente décennie (à l'époque, justement, où il nous fallait suivre UML qu'on a fini par déserter).

      Supprimer
  3. moi j'étais dans la gestion et la paie du perso
    Merise nous a bien aidé à prendre en compte toutes les attentes des utilisateurs de base

    RépondreSupprimer
    Réponses
    1. Oui mais Merise ne résoud pas la panne d'électricité au milieu des traitements. Ne me fais pas dire ce que je n'ai pas dit. Des milliers voire des centaines de milliers de types ont utilisé Merise. Je dis simplement que ces méthodes ne font pas tout et ne sont pas universelles.

      Supprimer
  4. on est d'accord ,une méthode d'analyse et rien d'autre

    RépondreSupprimer

La modération des commentaires s'active automatiquement deux jours après la publication des billets (pour me permettre de tout suivre). N'hésitez pas à commenter pour autant !