[Réaction]Programmation orientée objet, qu'est-ce que c'est

Tiens, pour faire le lien avec la discussion de ce matin sur l’UML. Moi je n’ai toujours pas bien compris à quoi ça correspondait, la POO, et je me dis que c’est peut-être là qu’un bon diagramme ça sert

Sinon, vous êtes plusieurs à dire que la POO n’est plus tant encensée que ça. Je l’ignorais, c’est un avis qui fait relativement consensus ? Pourquoi du coup ? (Moi j’étais effectivement resté sur l’idée d’il y a plusieurs années que c’êtait la panacée). Et on utilise quoi à la place ? Le procédural ? Ou j’ai l’impression une sorte de mix avec de la POO qui ne serait pas purement de la POO ?

Sinon, vous êtes plusieurs à dire que la POO n’est plus tant encensée que ça. Je l’ignorais, c’est un avis qui fait relativement consensus ?

C’est comme dans tous les domaines, il y a des modes et des tendances et on peut penser que la POO n’est plus autant en vogue qu’autrefois.

Et on utilise quoi à la place ? Le procédural ? Ou j’ai l’impression une sorte de mix avec de la POO qui ne serait pas purement de la POO ?

Le paradigme fonctionnel semble avoir connu une vague de popularité ces dernières années. Les langages qui sont nés ces dernières années se prétendent ouvertement fonctionnels (mais pas forcément exclusivement fonctionnel) et ne cachent pas leurs inspirations. Je pense notamment à Rust (2010) qui hérite fièrement des langages à la ML ou de Clojure (2007) qui est carrément un Lisp. On peut aussi penser à Java qui a introduit les lambdas dans le langage, fonctionnalité jusqu’à là plutôt cantonnée aux langage fonctionnels.

Évidemment, beaucoup de langages avaient déjà des traits de fonctionnel, dans le sens où il a toujours ou presque été possible d’adopter un style caractéristique du paradigme : fonction anonymes (lambda), closures, fonction en tant qu’objets de premier ordre qu’on trouve en Python, JavaScript, ou même PHP. Mais cela ne veut pas dire pour autant que les communautés respectives de ces langages approuvaient l’usage massif de ce style, alors que dans d’autres langages comme Haskell ou OCaml ça me semblait être la norme.

C’est possible de faire du Python à la Haskell en sortant functools, reduce, map, en composant tout et n’importe quoi etc. Mais ça ne serait pas considéré comme un code pythonique, dans ce cas.

Cela montre qu’au delà de ce qu’offre techniquement le langage, il y a aussi une notion d'usage à prendre en compte pour affirmer clairement « ce langage est fonctionnel ». Dans ce sens, j’ai l’impression qu’il devient de plus en plus admis d’adopter des patterns fonctionnels là où autrefois on allait privilégier un style typique de l’OO. (sans exagérer non plus)

Cependant, je n’ai pas l’impression que ça remplace la POO comme certains le pensaient/l’espéraient. J’ai plutôt l’impression que les nouveaux langages (ou grosses versions de langage) essaient de prendre le meilleur des deux mondes en faisant une sorte de mix, comme tu dis.

Je précise que ma réflexion est assez spéculative. C’est un ressenti et mes impressions sur ces dernières années.

, et je me dis que c’est peut-être là qu’un bon diagramme ça sert

les diagrammes UML sont parfois simples à comprendre (mais j’ai déjà mis du temps à écrire mon billet, j’avais la flemme de doubler le temps juste pour des graphes) mais ils restent un formalisme très très très abstrait. Du coup souvent on en revient au code pour comprendre le but de la conception.

Sinon, vous êtes plusieurs à dire que la POO n’est plus tant encensée que ça

Globalement, la POO, c’est un outil ultra efficace pour organiser des projets et permettre à des équipes de maintenir des projets sur le long terme. Du coup c’est encore très utilisé. Mais c’est cet aspect structurel qui est très mis en avant plus que l’aspect opérationnel. Aujourd’hui, dans l’opérationnel, c’est surtout l’expressivité qui compte. Et là les langages OO, très verbeux, vont beaucoup chercher des concepts dans d’autres paradigmes (fonctionnel notamment) pour créer des pipelines de traitement.

C’est élégant (et à ce jeu LINQ, le langage dans le langage qu’on trouve dans .NET et qui permet de manipuler des ensembles de données en mélangeant SQL et fonctionnel est vraiment le summum de l’expressivité et de l’élégance) mais on en revient toujours à l’OO quand il faut structurer, documenter, concevoir.

Les langages purement fonctionnels sont pas mal limités à des niches (haskell pour le parsing par exemple).

Pour autant pas mal de langages arrivent avec leurs organisations, leurs concepts et leurs implémentations qui chamboulent un peu tout ça.

Pendant que tout le monde cherche à mettre de l’OO en forçant au talon dans JS, des langages comme Go viennent avec des moyens de structurer le code assez KISS et c’est assez jouissif à la fin, même si en contrepartie il y a plein de pièges à éviter, mais le tooling (go vet était un ami fidèle à l’époque, je pense que ça l’est toujours) permet de détecter tous les eccueils.

Aujourd’hui, on va parler de "Data Driven Development" de ce que j’ai compris, notamment avec Go et Python. La POO de python devient alors un simple outil. Je dirais que l’intégration des Stream dans java et tout l’ajout fonctionnel qu’on a eu avec j8 et j9 est aussi dans cette veine.

Sinon, vous êtes plusieurs à dire que la POO n’est plus tant encensée que ça.

Je fais partie des gens qui disent ça, mais c’est vrai que ça mérite quelques explications.

Je l’ignorais, c’est un avis qui fait relativement consensus ?

Si on regarde les derniers langages qui sont sortis depuis 10 ans, et à quelques exceptions près (notamment côté frontend où on retrouve des langages comme TypeScript ou Dart qui sont très… classiques), on remarque une nette rupture avec les langages OO d’avant. Côté backend et système, ni Go, ni Rust, ni Zig, ni… ne reproduisent vraiment les concepts de classe ou d’héritage.

Le problème, c’est que l’on sait de longue date que l’Orienté Objet "pur" est difficile à utiliser correctement : on a d’un côté les explications de base sur l’encapsulation, le passage de messages, la composition, de l’autre des tas de règles parfois obscures (Open Closed Principle, Liskov Substitution Principle), des notions encore plus compliquées pour les expliquer (invariants, covariants, contravariants…), et depuis les années 1990, des tas de recettes de cuisine avec les Object Oriented Design Patterns. On est loin du super paradigme qu’on peut secouer comme une baguette magique au-dessus d’un problème pour le rendre facile à résoudre, qui guérit les cors au pieds et résout la faim dans le monde, que l’article de Futura Sciences nous vend : on est sur un concept qui non seulement demande de l’expérience et un long apprentissage pour le maîtriser correctement, mais qui en plus déjoue l’intuition, sans le sens où ce que les gens qui débutent vont d’abord concevoir intuitivement s’avère être le plus souvent la pire solution à un problème donné.

Depuis les années 1990, on observe que les gens qui se forment à la POO font de leur mieux avec ce qu’ils ont. Il y a 20 ans, la mode était de coller de l’héritage partout, ce qui aboutissait à d’immenses arbres de relations entre les classes… qui finissaient par se casser la figure (n’importe quel livre parlant un tant soit peu techniquement de programmation de jeux vidéo expose très vite les limites de cette approche, qui sont assez proches de ce que le Javaquarium met en évidence). Et c’est notamment pour cette raison que les langages modernes reprennent ce qui est utile de la POO (le polymorphisme par interfaces — ou traits comme les appelle Rust — par exemple) tout en prenant bien soin de se défaire des nids à poussière (l’héritage est devenu un tabou à peu près absolu, etc.).

Ce qui m’a fait personnellement grincer des dents avec l’article que cite @artragis, c’est qu’il présente la POO comme à la fin des années 90 où on vendait des langages corporate à des managers qui ne pigeaient rien à la programmation, comme si les vingt dernières années n’avaient pas eu lieu.

Et c’est notamment pour cette raison que les langages modernes reprennent ce qui est utile de la POO (le polymorphisme par interfaces — ou traits comme les appelle Rust — par exemple) tout en prenant bien soin de se défaire des nids à poussière (l’héritage est devenu un tabou à peu près absolu, etc.).

Un point intéressant, il est à noter que ça ne dispense pas totalement les développeurs de devoir se frotter à des notions de théorie des types. Par exemple, la notion de variance que tu mentionnes apparaît dans Rust avec les durées de vie longues qui sont vues comme un sous-type des durées de vie plus courtes qu’elles contiennent (ce qui permet d’enforcer par construction toutes les contraintes souhaitées sur les durées du vie, c’est plutôt élégant). En pratique, c’est souvent masqué, mais ça peut pointer le bout de son nez lors du développement de structure de données par exemple.

J’imagine que la seule stratégie pour se débarrasser totalement de ces considérations est soit de ne pas traiter le polymorphisme, soit avoir un système de types qui ne garantit pas grand chose d’intéressant.

A propos de l’OO je me permets de ressortir ça : https://zestedesavoir.com/billets/3116/causerie-episode-4/

de l’autre des tas de règles parfois obscures (Open Closed Principle, Liskov Substitution Principle), des notions encore plus compliquées pour les expliquer (invariants, covariants, contravariants…)

Autant plein de concepts sont obscures (parce que justement mal définis), autant je trouve que comprendre le LSP avec juste quelques bases en logique de Hoare (qui n’est pas très compliquée à piger), ça semble assez simple. Il faudrait que j’écrive un billet là dessus à l’occasion. Mais si tu comprends la règle d’affaiblissement en logique de Hoare, le LSP en découle de manière directe.

Comprenons-nous bien, quand je parle de truc obscurs ou compliqués à piger, je ne parle pas de moi qui me traîne pratiquement 15 ans de carrière. Je parle du point de vue des gens qui apprennent à programmer.

Typiquement le genre de gens qui seraient déroutés quand on leur parle du LSP, et encore plus quand on leur dit que c’est facile si on passe par un autre truc au nom barb-Hoare.

La cible de l’article de Futura-Science, quoi.

PS : quoique l’article semble s’adresser à des data scientists, qui, a priori, savent réagir sainement face à des notions théoriques inconnues…

Ben pour moi, il y a une question plus fondamentale là. Est ce que c’est normal si quelqu’un qui apprend à programmer ne reçoit pas au passage les notions théoriques de base sur lesquelles reposent le fonctionnement d’un programme ? (et je dis ça en ayant eu l’occasion de voir ces notions qu’après mon Master alors que clairement la logique de Hoare ne nécessite pas le bagage technique et théorique d’un Master).

Quelque part, doit on considérer le développement comme de l’artisanat (avec ses astuces, ses bonnes pratiques et de quelque part, amener par là une importance extrêmement forte à l’empirisme et l’expérience de l’artisan) ou comme un métier "technico-scientifique" (avec des fondements de théorique de base et qui ont une importance plus ou moins grande selon la tâche à réaliser, mais où l’on vise à remplacer au maximum l’empirisme parce des éléments tangibles) ?

Personnellement, j’ai tendance à considérer que l’on devrait plutôt viser la seconde, c’est pas un avis forcément partagé, c’est simplement en ligne avec le fait que je pense que l’on devrait au maximum être capable d’expliquer de manière mesurable pourquoi on a confiance dans la qualité de tel ou tel système (et d’indiquer nos points d’incertitude).

Quelque part, doit on considérer le développement comme de l’artisanat (avec ses astuces, ses bonnes pratiques et de quelque part, amener par là une importance extrêmement forte à l’empirisme et l’expérience de l’artisan) ou comme un métier "technico-scientifique" (avec des fondements de théorique de base et qui ont une importance plus ou moins grande selon la tâche à réaliser, mais où l’on vise à remplacer au maximum l’empirisme parce des éléments tangibles) ?

Mon point de vue c’est que ces deux aspects ne sont pas du tout mutuellement exclusifs, qu’ils se conjuguent et même se complètent dans le métier d’ingénieur en développement logiciel. En ce sens, quelqu’un qui viserait tout l’un ou tout l’autre ne pourrait pas faire un bon développeur à mes yeux.

Bref, pour moi il faut impérativement cultiver les deux et faire progresser les deux aspects, car les deux visions sont d’importance égale dans le métier.

PS : De la même manière, dans un tout autre domaine, on ne peut pas considérer le jazz comme une activité purement intellectuelle, ni purement technique, ni purement artisanale. Un bon musicien de jazz maîtrise beaucoup de théorie, et dispose d’un savoir faire et d’une intuition qu’il a cultivés avec des années de pratique : s’il n’avait pas les deux, ce ne serait pas un bon musicien. Pareil pour la médecine…

Ben quelque part, c’est mon point. Actuellement, j’ai l’impression (mais je peux me tromper), qu’on a tendance à tout placer à l’extrémité artisanat du spectre et qu’il manque certains fondamentaux dans l’apprentissage du développement. On enseigne des "bonnes pratiques" mais sans les recaler dans le fondement théorique de base.

Je vois les choses un peu différemment.

D’un côté je partage ton observation : on enseigne des bonnes pratiques un peu comme des recettes de grand-mère. Ce qui fait s’arracher les cheveux aux gens qui connaissent la théorie.

De l’autre, on a également le phénomène opposé : les écoles d’informatique en France semblent aborder son enseignement comme si on pouvait faire des cours magistraux avec deux trois projets encadrés puis lâcher les jeunes diplômés dans la nature en considérant qu’on en a fait des professionnels compétents puisqu’ils ont bien bossé leurs cours.

Résultat, les jeunes diplômés ne maîtrisent ni la théorie (car ce n’est pas la théorie "qui importe" qui est enseignée), ni le métier (par contre ils ont des jolies connaissances théoriques sur Agile et le management de projet).

C’est pour ça que je dis qu’il ne faut pas voir ça comme un curseur à placer entre deux idéaux : que l’on se place du point de vue de la théorie comme de celui du software craftsmanship, l’enseignement du développement marche sur la tête et les pratiques des entreprises sont le plus souvent complètement à côté de la plaque.

Il y a énormément de progrès à faire des deux points de vue. Si l’aspect artisanal était si soigné que cela, on se taperait vachement moins de bloatwares et les 3/4 des blagues des "joies du code" seraient caduques.

De l’autre, on a également le phénomène opposé : les écoles d’informatique en France semblent aborder son enseignement comme si on pouvait faire des cours magistraux avec deux trois projets encadrés puis lâcher les jeunes diplômés dans la nature en considérant qu’on en a fait des professionnels compétents puisqu’ils ont bien bossé leurs cours.

J’ai pas des années de carrière, mais je ne pense pas avoir rencontré un seul prof dans l’académique défendant qu’un étudiant qui sort de la fac ou d’une école d’ingé est opé pour bosser immédiatement dans un milieu professionnel. Mon observation n’est pas sur la formation académique mais sur la formation "au global", c’est à dire en cumulant l’académique, l’autoformation et la formation pro fournie par la boîte où l’on bosse.

Résultat, les jeunes diplômés ne maîtrisent ni la théorie (car ce n’est pas la théorie "qui importe" qui est enseignée), ni le métier (par contre ils ont des jolies connaissances théoriques sur Agile et le management de projet).

Je vois trop souvent des collègues céder à des demandes absurdes du monde indus alors qu’ils n’ont pas les compétences pour assurer ces cours . Sans parler de ceux qui cèdent à "dernière techno à la mode" alors qu’ils savent pertinemment qu’ils n’ont pas le temps de produire un nouveau cours dessus.

Il y a énormément de progrès à faire des deux points de vue. Si l’aspect artisanal était si soigné que cela, on se taperait vachement moins de bloatwares et les 3/4 des blagues des "joies du code" seraient caduques.

J’ai dit qu’on se focalisais dessus, pas qu’on le faisait bien