C'est l'histoire d'une collision entre l'anatomie d'une erreur de 35 ans : la hiérarchie au moment de la compilation d'une encapsulation qui correspond au modèle du domaine par Casey Muratori d'une part, et la mort de Gianni Versace d'autre part. Quel point commun en-dehors d'une conjonction temporelle entre un visionnage de série et celui d'une conférence me direz-vous ? La réponse est simple, car dans le titre : l'héritage.
Dans cette conférence on trouve en particulier à 13:02 une citation de Bjarne Stroustrup, le père de C++, qui dit que programmer de manière orientée objet (POO) c'est programmer en utilisant l'héritage, et la fameuse hiérarchie est issue directement de l'héritage.
Alors qu'est-ce que l'héritage en POO ? Le terme est-il bien choisi ? Tout d'abord regardons une définition issue du TLFi : "patrimoine que laisse une personne à son décès; patrimoine recueilli par voie de succession". La question qui se pose immédiatement est : quel code est décédé ? On connaît tous les codeurs disparus, ceux qui sont effectivement remplacés par l'IA, mais par définition ils n'ont pas vraiment laissé d'héritage.
Regardons un deuxième sens : "Ce qui est transmis par les générations précédentes, ce qui est reçu par tradition. Héritage culturel, littéraire, national, romantique; héritage de coutumes, de croyances, des traditions; héritage des classiques, des Grecs, des Latins." Quelque part, on est en train de parler de connaissances, au mieux de savoir-faire, comme une bonne pratique dont on aurait oublié l'origine et le contexte.
En C++ l'héritage est essentiellement la capacité à profiter du comportement (ou code) de son ancêtre, sans qu'il en soit dépossédé. En C++ peut-on renoncer à son héritage ? Pas vraiment, on peut surcharger ou redéfinir un comportement, mais on ne peut pas faire comme s'il n'existait pas. Deuxième point de divergence. Est-ce que l'héritage fait d'un descendant en C++ un privilégié dans cette société de classes ? Le jury ne se prononce pas, mais ça n'en a pas l'air.
Mais alors, avait-on le choix ? Un meilleur terme à proposer ? C'est un peu comme si chaque descendant exposait au moins les mêmes boutons que ses ancêtres, et, surprise, le comportement derrière ces boutons pouvait changer de génération en génération, sachant que toutes les générations sont vivantes simultanément. Rien ne raisonne directement avec cet exposé. Tout au plus, si on veut anthromorphiser le sujet (ce qu'adorent faire les vulgaires vulgarisateurs de tout poil (synthétique évidemment)), on pourrait penser à un client qui s'adresse à un consultant, et ce consultant fait lui-même ou demande à sa chaîne hiérarchique de faire à sa place. Comme dans tout cabinet de conseil en quelque sorte : on missionne un junior, avec l'espoir d'avoir le comportement (par l'implication) du senior, voire du manager, en cas de problème.
En cabinet de conseil, on n'hérite de rien, cette chaîne hiérarchique s'établie par réseautage (le retour de Bachman !) ou par piston. On retrouve cette idée en C++ du comportement poussé ou déversé par l'ancêtre sur son descendant. De là à parler d'incontinence de classe ? Pourquoi pas.
Post-scriptum : il s'avère qu'un meilleur terme qu'héritage était présent depuis le début, dans C++ ou d'autres langages. "Etendre". Avec les classes, cette hiérarchie ne naît pas par héritage, mais par extension du domaine.
Vous pouvez trouver le reste de la série sous l'article d'introduction.
