C++ – Polymorphisme (dynamique)

Héritage

L'héritage consiste à regrouper des méthodes et des propriétés communes à un ensemble de classes sous l'égide d'une classe ancêtre leur étant commune. Toutes les classes descendant (dérivant) d'un ancêtre commun hériteront des propriétés et des méthodes de cet ancêtre[1]. L'idée ici est de maximiser la réutilisation du code existant.

Ce principe est implanté en C++ de façon riche et complexe – trop, en fait, pour notre petite discussion du polymorphisme. Nous restreindrons, dans ce qui suit, notre approche à l'héritage dit public.

class Base {
   // ...
};
// Derivee est un cas particulier de Base.
// Une instance de Derivee est tout ce qu'est une instance
// de Base, plus ce qui est specifique à Derivee
class Derivee : public Base {
   // ...
};
int main() {
   Base b;
   Derivee d;
}

Les instances d'une classe héritent des membres publics ou protégés de la classe de laquelle leur propre classe est dérivée. Par exemple :

class Base {
   int val_ {};
public:
   Base() = default;
   Base(int val) : val_{ val } {
   }
   int valeur() const noexcept {
      return val_;
   }
protected:
   void valeur(int val) noexcept {
      val = val;
   }
};
struct Derivee : Base {
   Derivee(int val) : Base{val} {
   }
   // utilise les méthodes du parent
   void doubler() noexcept {
      valeur(valeur() * 2);
   }
};
#include <iostream>
int main() {
   using namespace std;
   int valeur;
   if (cin >> valeur) {
      Derivee d{ valeur };
      d.doubler();                // valide: d est une Derivee
      cout << d.valeur() << endl; // valide: d est aussi une Base 
   }
}

L'héritage est cumulatif. Chaque classe hérite de son[2] parent, et de tout ce dont son parent avait lui aussi hérité.

Notez qu'une classe n'hérite pas (du moins, pas visiblement) des membres privés de son parent. Ceci rejoint le principe d'encapsulation : cachez les propriétés d'une classe sous sa rubrique private, et construisez-lui des accesseurs et des mutateurs « propres » (dans les deux sens du terme), qui garantissent son intégrité. Ses descendants, en passant par l'interface publique de cet ancêtre, pourront tirer profit des atouts d'implantation de leur parent, mais sans avoir à se préoccuper des détails qui leur sont associés.

Polymorphisme

#include <iostream>
struct B {
   // attention: incomplet!
   void M() {
      std::cout << 2 << std::flush;
   }
};

struct D1 : B {
   // même signature que B::M()
   void M() {
      std::cout << 4.75 << std::flush;
   }
};
struct D2 : B {
   // même signature que B::M()
   void M() {
      std::cout << "Yo!" << std::flush;
   }
};
int main() {
   B *tab[] = {
      new B,
      new D1,
      new D2
   };
   enum { N = sizeof(tab) / sizeof(tab[0]) };

   for (int i = 0; i < N; ++i) {
      tab[i]-> M();
      delete T[i];
   }
}

Le programme affichera 222. Voici pourquoi :

• Pour un B, la méthode M() a pour tâche d'effectuer l'opération cout << 2 << flush;
• Dans la fonction main() de notre exemple, on trouve un tableau de B*
• La boucle appelle la méthode M() du B pointé par chaque tab[i]. Cela a pour effet d'appeler B::M() dans chaque cas, ce qui affichera à chaque fois 2

// ...
int main() {
   B *tab[] = {
      new B,  new D1,  new D2, nullptr
   };
   for (int i = 0; tab[i]; ++i) {
      tab[i]-> M();
      delete tab[i];
   }
}

Mais est-ce nécessairement ce qu'on aurait voulu? Réécrivons notre programme principal de façon légèrement différente :

int main() {
   // Remarquez la différence dans les déclarations...
   B b;
   D1 d1;
   D2 d2;
   // ...de même que dans les appels. Un peu moins agréable, non?
   b.M();
   d1.M();
   d2.M();
}

Celui-ci affichera plutôt 24.75Yo!. Cela vous semble-t-il étrange? C'est le genre de truc qui mérite réflexion.

Dans la premier cas, nous avions un tableau tab de pointeurs à des B qui pointaient effectivement sur un B, un D1 et un D2. L'appel de leurs méthodes M() appelait toutefois B::M() dans chaque cas du fait que pour main(), tab est de type B*.

Dans le deuxième cas, nous avons une instance de B, une autre de D1 et une de D2. Or, il se trouve que l'appel de leurs méthodes M() respectives dans la fonction main() appelle tour à tour B::M(), D1::M() et D2::M().  Cela se produit parce que main() connaît leur type effectif – ici, b est clairement de type B, d1 de type D1 et d2 de type D2.

On a donc affaire ici à deux segments de code fort similaires, qui traitent (au fond) des mêmes types d'objets et à peu près de la même manière, tout en obtenant des résultats différents. Ceci peut sembler un problème académique, mais c'est en fait un irritant très concret pour un(e) informaticien(ne).

Il peut pourtant arriver assez fréquemment qu'on veuille que la méthode la plus spécialisée soit appelée dans chaque cas. Appeler la méthode la plus spécialisée possible étant donné une indirection (pointeur ou référence) vers un objet est précisément ce que fait le mécanisme qu'on nomme polymorphisme.

Voici deux exemples où le polymorphisme serait souhaitable.

void afficher_formes(Forme *tete) {
   while(tete) {
      tete->afficher(); // magie?
      tete = tete->prochain();
   }
}

int n;
Piece *p[NB_PIECES] = { nullptr };
// remplir le tableau
initialiser_pieces(p, NB_PIECES);
do {
   cout << "Bouger quelle pièce?";
   cin >> n; // à valider
} while (n < 0 || MAX_PIECES <= n);
p[n]->deplacer(); // magie?

Nous allons nous concentrer sur un cas simple : une classe Personne, écrite de façon à ce que chaque personne ait un nom et, sur demande, nous dise qui elle est.

Mise en application

On dérivera de Personne les classes Gars et Fille de façon à ce que, si on demande à un Gars qui il est, il réponde "Mr. " suivi de son nom, et de façon à ce que si on demande plutôt à une Fille qui elle est, elle réponde "Mme " suivi de son nom.

La classe Personne ira comme suit.

#include <string>
class Personne {
public:
   using str_type = std::string;
private:
   str_type nom_;
public:
   Personne(const str_type &nom) : nom_{ nom } {
   }
   virtual ~Personne() = default;
   str_type nom() const {
      return nom_;
   }
   virtual str_type qui_suis_je() const {
      return nom();
   }
};

Remarquez que qui_suis_je() peut être est const car elle ne fait affaire qu'avec des méthodes const, assurant ainsi l'intégrité de l'instance active.

Remarquez aussi le précieux mot clé virtual : c'est sur lui que repose, en C++, le polymorphisme.

D'ailleurs, essayez à nouveau l'exemple plus haut (celui utilisant un tableau de B*) avec les classes B, D1 et D2 en n'apportant que la modification suivante.

struct B {
   virtual void M() {
      std::cout << 2 << std::flush;
   }
   virtual ~B() = default;
};

Vous verrez que le simple ajout de ce mot clé à la classe où est déclarée la méthode M() fait en sorte que le programme principal appelle la méthode M() la plus spécifique dans chaque cas. Aucun autre ajout n'est requis au code.

int main() {
   B *tab[] = {
      new B, new D1, new D2, nullptr
   };
   for(int i = 0; tab[i]; ++i) {
      tab[i]->M(); 
      delete tab[i];
   }
}

Poursuivant avec notre exemple de Gars et de Fille, on pourra écrire :

struct Gars : Personne {
   Gars(const str_type &nom) : Personne{ nom } {
   }
   str_type qui_suis_je() const {
      static const str_type PREFIXE = "Mr. ";
      return PREFIXE + nom();
   }
};
struct Fille : Personne {
   Fille(const str_type &nom) : Personne{ nom } {
   }
   str_type qui_suis_je() const {
      static const str_type PREFIXE = "Mme ";
      return PREFIXE + nom();
   }
};

À partir de ces classes, on pourra écrire le programme suivant, qui affichera sur deux lignes différentes "Mr. Guy" et "Mme Sylvie":

#include "Personne.h"
#include <iostream>
using namespace std;
void presenter(ostream &os, const Personne &p) {
   os << p.qui_suis_je() << endl;
}
int main () {
   Gars g = "Guy";     // Gars  : public Personne
   Fille f = "Sylvie"; // Fille : public Personne
   presenter(cout, g);
   presenter(cout, f);
}

Même si p dans presenter() est de type const Personne&, la mécanique de C++, constatant que qui_suis_je() est spécifiée virtual, identifiera à l'exécution que p pointe plus précisément vers un Gars ou plus précisément vers une Fille. Notant qu'il existe pour ces deux types des versions plus spécifiques de la méthode qui_suis_je(), cette version sera celle qui sera utilisée lors de l'appel.

Implantation avec classe abstraite

Il arrive des cas où une classe devrait servir de modèle à un ensemble d'autres classes, mais ne devrait jamais être directement instanciée. Par exemple, on peut imaginer afficher un carré, un cercle ou un losange, mais on ne peut s'imaginer afficher une forme; c'est là quelque chose de trop abstrait.

On aimerait toutefois traiter toutes les formes en fonction de certains points communs. Entre autres, on aimerait que toutes les formes puissent être affichées, et que si on manipule un tableau de formes, il soit possible d'écrire quelque chose comme ce qui suit.

void tres_cool() {
   Forme *tab[] = { new Carre, new Cercle, new Triangle };
   enum { N = sizeof(tab) / sizeof(tab[0]) };
   for (int i = 0; i < N; ++i) {
      tab[i]->afficher(); // vive le polymorphisme!
      delete tab[i];
   }
}

... ou encore, plus simplement, en utilisant une répétitive for sur un intervalle :

void tres_cool() {
   Forme *tab[] = { new Carre, new Cercle, new Triangle };
   for (auto p : tab) {
      p->afficher(); // vive le polymorphisme!
      delete p;
   }
}

En revanche, on voudrait qu'il soit impossible de faire ce qui est proposé à droite...

void pas_raisonnable() {
   Forme f;       // ou Forme *f = new Forme;
   f.afficher(); // ou f->afficher()
}

...parce qu'on serait bien mal pris d'essayer d'exprimer l'affichage d'une forme abstraite. Dans ce genre de cas, on a recours à ce qu'on appelle une classe abstraite.

Une classe abstraite est une classe qui ne peut en aucun cas être instanciée directement, mais dont on peut dériver des sous-classes qui, elles, le seront. Une classe abstraite (p. ex. : Forme) regroupera les traits communs à toutes ses classes dérivées (p. ex. : Cercle, Carre) et permettra de traiter des instances de chacune de ces dérivées comme une instance de la classe abstraite.

Par exemple, on pourrait logiquement ne pas vouloir instancier directement la classe Forme, prétextant qu'une Forme abstraite n'a pas de sens en soi, mais on pourrait vouloir traiter (par polymorphisme, bien entendu) toutes les formes de la même façon, selon un même modèle.

Une classe abstraite, en C++, est une classe qui a au moins une méthode virtuelle dite « pure ». Une méthode virtuelle pure est une méthode virtuelle pour laquelle on n'indique pas de définition, et à laquelle on appose le suffixe = 0.

 // cette classe est abstraite à cause de sa méthode f()
class Abstraite {
   // ...
public:
   // cette méthode est une méthode pure virtuelle, donc abstraite
   virtual int f() = 0;
   virtual ~Abstraite() = default;
};
class PasAbstraite { // cette classe n'est pas abstraite
   // ...
public:
   virtual int f(); // virtuelle, mais pas abstraite
   virtual ~PasAbstraite() = default;
};

#include <iosfwd>
struct Forme {
   virtual ~Forme() = default;
   // La classe est abstraite car elle
   // a au moins une méthode virtuelle
   // pure (= 0). Cette méthode ne sera
   // pas définie pour la classe Forme.
   virtual void afficher(std::ostream &) const = 0;
};

#include "Forme.h"
#include <iostream>
class Carre : public Forme {
   int hauteur_;
public:
   int hauteur() const noexcept {
      return hauteur_;
   }
   int largeur() const noexcept {
      return hauteur();
   }
   Carre(int hauteur) noexcept : hauteur_{hauteur} {
   }
   // Carre n'est pas abstraite car elle n'a
   // pas de méthode virtuelle pure – celle
   // qui suit remplace (surcharge) celle de
   // son parent (Forme)
   void afficher(std::ostream &os) const {
      using std::endl;
      for (int i = 0; i < hauteur(); ++i) {
         for (int j = 0; j < largeur(); ++j)
            os << "*";
         os << endl;
      }
   }
};

Implantée comme classe abstraite, la classe Personne aurait l'air de ceci :

#include <string>
class Personne {
public:
   using str_type = std::string;
private:
   str_type nom_;
public:
   Personne(const str_type &nom) : nom_{ nom } {
   }
   virtual ~Personne() = default;
   str_type nom() const {
      return nom_;
   }
   virtual str_type qui_suis_je() const = 0;
};

Remarquez qu'on peut avoir autant de méthodes « normales » qu'on le veut dans une classe abstraite (ou non); une classe devient abstraite si elle a au moins une méthode virtuelle pure – ici, la méthode qui_suis_je().

Les classes Gars et de Fille n'ont pas à changer suite à cet ajustement fait à leur parent (ce qui est une bonne chose – les changements locaux sont beaucoup moins coûteux en entretien que les changements dont les répercussions sont vastes et étendues). Du code dans lequel il est possible de localiser les changements est de facto plus rétilisable que du code ne respectant pas cette règle. L'encapsulation est un outil conceptuel précieux et une pratique essentielle au développement de logiciels de qualité.

// ...
#include "Personne.h"
struct Gars : Personne {
   Gars(const str_type &nom) : Personne{ nom } {
   }
   str_type qui_suis_je() const {
      static const str_type PREFIXE = "Mr. ";
      return PREFIXE + nom();
   }
};
struct Fille : Personne {
   Fille(const str_type &nom) : Personne{ nom } {
   }
   str_type qui_suis_je() const {
      static const str_type PREFIXE = "Mme ";
      return PREFIXE + nom();
   }
};

Le sous-programme suivant montre ce qu'il est permis – et ce qu'il est interdit – de faire si on manipule des classes abstraites.

#include "Personne.h"
#include "Gars.h"
#include "Fille.h"
#include <iostream>
int main() {
   using namespace std;
   // Personne p;   // Serait illégal: Personne est abstraite!
   Personne *pp; // Légal
   Gars g{ "Guy" };  // Légal
   Fille f{ "Sylvie" }; // Légal
   Personne* tab[2] = { &g, &f }; // Légal
   // pp = new Personne; // Serait illégal: Personne est abstraite!
   // Polymorphisme!
   cout << tab[0]->qui_suis_je() << endl  // Gars  :: qui_suis_je()
        << tab[1]->qui_suis_je() << endl; // Fille :: qui_suis_je()
}

Mauvaise pratique : l'« antipolymorphisme »

Le polymorphisme remplace une pratique du passé qu'il serait, désormais, de mise de qualifier d'« antipolymorphisme ». Ce qui suit donne un exemple de cette mauvaise pratique, puisqu'elle est encore possible et peut être utile dans des cas très ciblés[3], mais sans plus.

Par antipolymorphisme, on parle d'étiqueter un type (par un entier ou une valeur énumérée, par exemple) et de déterminer manuellement les opérations qui lui sont applicables sur la base de cette étiquette. Par exemple :

enum class Sorte { carre, cercle, triangle };
class Forme {
   Sorte sorte;
   // ...
public:
   Forme(Sorte sorte) : sorte{sorte) {
   }
   // ...
   void dessiner() {
      switch(sorte) {
      case Sorte::carre:
         // dessiner un carré
         break;
      case Sorte::cercle:
         // dessiner un cercle
         break;
      case Sorte::triangle:
         // dessiner un triangle
         break;
      default:
         // erreur...
         ;
      }
   }
};

Autre signe d'antipolymorphisme : opérer au mauvais niveau d'abstraction. Par exemple :

class Volume {
   // trucs propres à un volume
public:
   virtual ~Volume() = default;
   // ...
};
class Sphere : public Volume {
   // trucs propres à une sphère
};
class Boite : public Volume {
   // trucs propres à une boîte
};
//
// quelle horreur! Lourd, lent, complexe, et un cauchemar à entretenir lors de l'ajout de types de volumes!
//
bool collisionner(const Volume &v0, const Volume &v1) {
   if (auto a = dynamic_cast<const Sphere*>(&v0); a != nullptr) {
      if (auto b = dynamic_cast<const Sphere*>(&v1); b != nullptr) {
         // tester une collision Sphere / Sphere entre *a et *b
      } else if (auto c = dynamic_cast<const Boite*>(&v1); c != nullptr) {
         // tester une collision Sphere / Boite entre *a et *c
      } else {
         // type de volume imprévu... lever une exception?
      }
   } else if (auto aa = dynamic_cast<const Boite*>(&v0); aa != nullptr) {
      if (auto b = dynamic_cast<const Sphere*>(&v1); b != nullptr) {
         // tester une collision Boite / Sphere entre *aa et *b
      } else if (auto c = dynamic_cast<const Boite*>(&v1); c != nullptr) {
         // tester une collision Boite / Boite entre *aa et *c
      } else {
         // type de volume imprévu... lever une exception?
      }
   } else {
      // type de volume imprévu... lever une exception?
   }
}

L'antipolymorphisme mène à du code difficile à entretenir :

• L'ajout de chaque nouveau cas à traiter entraîne plusieurs changements à plusieurs endroits dans le projet, ce qui en complique l'entretien
• L'écriture de fonctions antipolymorphiques (qui doivent poser des gestes sur la base de l'étiquette décrivant le type) implique chaque fois une sélective (ou un équivalent) qui doit être tenu à jour
• Il devient ardu de localiser à même un type les opérations spécialisées pour ce type

En bref, l'antipolymorphisme transforme l'évolution du code source en cauchemar. Par opposition, le polymorphisme simplifie drastiquement l'évolution d'un programme :

• Ajouter un type est (entre autres) une opportunité de spécialiser des comportements
• Les spécialisations sont locales et circonscrites
• Il est possible d'ajouter des types à un programme une fois celui-ci compilé, dans la mesure où le mécanisme servant à en fabriquer des instances est suffisamment opaque.

Lectures complémentaires

Quelques liens pour enrichir le tout.

• Que faire quand le polymorphisme échoue? Texte de 2004 par Steve Yegge, mais je dois admettre que ces cas sont d'abord et avant tout des fautes de design : https://sites.google.com/site/steveyegge2/when-polymorphism-fails
• Le sympathique Julien Gilli, de la cohorte 03 au DDJV de l'Université de Sherbrooke, m'a suggéré http://www.cs.ucsb.edu/~urs/oocsb/papers/TRCS99-24.html qui est un texte costaud, par Karel Driesen en 1999, sur diverses manières d'implémenter le polymorphisme efficacement.
• Série de textes fort intéressants et suggérant de repenser le polymorphisme, par Dean Michael Berris :
  • polymorphisme et sémantique de valeur, texte de 2012 : http://www.cplusplus-soup.com/2012/10/value-semantics-and-polymorphism.html
  • variations sur la pratique du polymorphisme, avec une approche se rapprochant de l'effacement de types, texte de 2012 : http://www.cplusplus-soup.com/2012/11/different-forms-of-polymorphism.html
• Comprendre l'impact des méthodes virtuelles sur la structure en mémoire des objets, texte de Dan Saks en 2012 : http://www.drdobbs.com/cpp/storage-layout-of-polymorphic-objects/240012098
• Discussion des nuances entre les concepts de surcharge et de polymorphisme, par Faye Williams en 2014 : http://www.codeproject.com/Articles/837146/Polymorphism-and-Overloading-in-Cplusplus
• En 2014, Łukasz Wojakowski disserte des mérites et des risques associés à l'apposition d'une qualification const à une méthode polymorphique : http://ljwo.wordpress.com/2014/11/07/to-const-or-not-to-const-the-liskov-substitution-principle/
• Texte de 2015 par Peteris Krumins sur ce qu'il nomme les quatre polymorphismes de C++ : http://www.catonmat.net/blog/cpp-polymorphism/
• En 2015, Manu Sánchez discute de polymorphisme non-intrusif : http://blog.biicode.com/about-non-intrusive-polymorphism/
• Survol animé du polymorphisme dynamique en C++, par Neil Moore en 2015 : https://slate.adobe.com/a/REYAE
• À propos de l'implémentation du polymorphisme dynamique en C++ :
  • textes de 2016 par Shahar Mike, portant sur la structure d'une vtbl :
    • http://shaharmike.com/cpp/vtable-part1/
    • http://shaharmike.com/cpp/vtable-part2/
    • http://shaharmike.com/cpp/vtable-part3/
    • http://shaharmike.com/cpp/vtable-part4/
  • en 2017, Pablo Arias examine la structure d'une vtbl : http://ariasalpablo.blogspot.ca/2017/05/understanding-virtual-tables-in-c.html
  • texte d'Arwin Nanjappa en 2017, qui examine le code machine généré pour une vtbl : https://codeyarns.com/2017/06/13/a-dissection-of-c-virtual-functions/
• Réflexion intéressante d'Edaqa Mortoray en 2016, portant sur les modalités du polymorphisme dans le code appelé :
  • https://mortoray.com/2016/08/10/the-very-real-mess-of-virtual-functions/
  • https://mortoray.com/2016/08/29/a-pattern-bandage-for-messy-virtual-functions/ (qui fait une critique de l'idiome NVI)
  • https://mortoray.com/2016/09/13/the-unfortunate-world-of-boilerplate-code/
• Il ne faut pas appeler une méthode virtuelle dans un constructeur ou dans un destructeur, comme le rappelle à juste titre ce texte de 2017 (en se basant sur cet autre texte de 2005 par Scott Meyers : http://www.artima.com/cppsource/nevercall.html) : https://embeddedartistry.com/blog/2017/2/27/never-call-virtual-functions-during-construction-or-destruction
• Comparaisons du polymorphisme dynamique classique à celui permis par le recours à std::variant :
  • texte de 2016 par Adi Shavit : http://videocortex.io/2016/polymorphism-polymorphism
  • texte de 2018 par Sumant Tambe : http://cpptruths.blogspot.ca/2018/02/inheritance-vs-stdvariant-based.html
• Le polymorphisme dans le moteur Unreal 4, décrit en 2017 par Steven To : http://www.brightdevelopers.com/unreal-engine-4-c-polymorphism-overview/
• Plusieurs réfléchissent à des manières plus contemporaines d'atteindre le polymorphisme dynamique :
  • Louis Dionne propose dyno, ce qu'il nomme le « Run-time polymorphism done right » : https://github.com/ldionne/dyno
  • Mathieu Ropert propose en 2017 une série d'articles inspirés de recherches menées par Sean Parent :
    • https://mropert.github.io/2017/11/30/polymorphic_ducks/
    • https://mropert.github.io/2017/12/17/better_polymorphic_ducks/
    • https://mropert.github.io/2017/12/23/undefined_ducks/
  • Sean Parent lui-même discute de ses recherches, et de quelques pièges qui se sont introduits dans sa démarche, dans ce texte de 2018 : http://stlab.cc/tips/small-object-optimizations.html
• Variation sur le thème du polymorphisme dynamique, proposée par Jonathan Boccara en 2020 : https://www.fluentcpp.com/2020/05/15/runtime-polymorphism-without-virtual-functions/
• En 2020, Kilian Henneberger propose une table de décision pour aider les programmeuses et les programmeurs à choisir une approche au polymorphisme. À vous de voir si elle vous sied : https://ukilele.github.io//2020/05/11/polymorphism-decision-table.html
• Quand un compilateur C++ peut-il réaliser de la dévirtualisation, sorte d'inlining d'une fonction virtuelle? Une analyse intéressante d'Arthur O'Dwyer en 2021 : https://quuxplusone.github.io/blog/2021/02/15/devirtualization/

[1] Ceci est une généralisation, car il y a des contraintes relatives au caractère privé, protégé ou public des membres.

[2] Ou de ses parents – en C++, l'héritage multiple est permis. Mais nous éviterons ici ce dossier.