Héritage multiple en C++ : pourquoi l'héritage d'interfaces est insuffisant

Bonjour à tous !

Je viens de mettre en ligne un article, intitulé : Héritage multiple en C++ : Pourquoi l'héritage d'interfaces est insuffisant

N'hésitez pas à faire donner votre avis, faire des remarques. L'article compare aussi des fonctionnalités de différents langages orientés objet, principalement C++, C# et Java. En tant que tel, j'espère qu'il pourra susciter des discussions intéressantes, sans sombrer dans le troll inter-langages.

Bonne lecture !

Super plaidoyer pour l'héritage multiple :bravo:

Enfin quelqu'un qui défend cette notion qu'il est "politiquement correct" de décrier.

Merci

juste 2 remarques :

Code:

---

assert(montant > solde());

---

J'espère que tu ne développe pas pour une banque !

Et au chapitre 3-B, je me demande si le 1er diagramme de classe est correct (classe A définie 2 fois), et s'il l'est, il me semble identique au 2eme (même si on comprend bien grace à ces 2 diagrammes ce que tu veux montrer).

Du bon boulot en tous cas.

jmv

Salut,
c'est un très bon papier


mais pour la partie 2B, je ne suis pas sur que l'héritage (multiple ou pas) soit la bonne solution, on dirait plutôt que quelqu'un a abusé de l'héritage. Dans ce cas, il faudrait plutot faire de la composition que de l'héritage (c'est un problème que je retrouve dans toutes les bibliothèques IHM que je connais; faire un widget c'est environ 8 niveaux d'héritage)

Citation:

---

Envoyé par jmv

juste 2 remarques :

Code:

---

assert(montant > solde());

---

J'espère que tu ne développe pas pour une banque !

---

Rassure toi, tu peux dormir sur tes deux oreilles :)

Citation:

---

Envoyé par jmv

Et au chapitre 3-B, je me demande si le 1er diagramme de classe est correct (classe A définie 2 fois), et s'il l'est, il me semble identique au 2eme (même si on comprend bien grace à ces 2 diagrammes ce que tu veux montrer).

---

En effet, je ne pense pas qu'UML permette d'exprimer cette notion, et mes diagrammes ne sont donc probablement pas des diagrammes UML standards. Encore un exemple qui démontre que malgré ses désirs d'universalité, UML a été pensé avec certains types de langages en tête, et ne permet pas vraiment de représenter toutes les notions de tous les langages.

Citation:

---

Envoyé par screetch

mais pour la partie 2B, je ne suis pas sur que l'héritage (multiple ou pas) soit la bonne solution, on dirait plutôt que quelqu'un a abusé de l'héritage. Dans ce cas, il faudrait plutot faire de la composition que de l'héritage (c'est un problème que je retrouve dans toutes les bibliothèques IHM que je connais; faire un widget c'est environ 8 niveaux d'héritage)

---

Je suis assez d'accord avec toi, le domaine de l'IHM abuse généralement des hiérarchies d'héritage profondes, et obligent souvent à dériver des classes fournies par la bibliothèque pour personnaliser le comportement (même si je trouve que la situation s'améliore, par exemple, en WPF, on peut faire moult personnalisations sans aucune dérivation, avec entre autre la notion de templates d'affichage qui permet d'indiquer comment un composant graphique logique va créer ses composants graphiques visuels).

Le fait est qu'il faut tout de même faire avec. Et si le cas des IHM est emblématique des cas où l'on doit dériver de classes d'une hiérarchie existante et non modifiable, il n'est pas le seul.

Article super intéressant :ccool:, à faire lire à tous les javateux et autres csharpeux qui ne comprennent pas pourquoi on se sent frustré quand on code dans leur langage chéri.

Seule petite remarque, je trouve dommage de présenter le NVI pour vérifier les contrats comme un avantage à l’héritage multiple de code. C’est plus un palliatif moins mauvais que ce qu’on a dans les autres langages. Théoriquement, les contrats font partie de l’interface de la fonction, pas de son code. Je ne l’aurais en tout cas pas mis en premier, je trouve les deux autres exemples beaucoup plus convaincants ;).

Très intéressant bravo !
Surtout que je me suis dev C# et qu'en se moment je me met au c++, ça tombe à pic :D.

J'ai survolé pour l'instant, mais je peut dire que sans héritage multiple, on peut aussi ne pas dupliquer de code, en général grâce à la composition.
ça évite aussi d'avoir des classes "qui font tout", 1ère chose à laquelle je pense quand je vois écrit héritage multiple.

En tout cas merci, j'ai hâte de m'y plonger ce soir :ccool:

Excellent, j'ai appris beaucoup de choses :)

Hello.
Super initiative. Je vais y gagner en moins de radotage grâce à toi :) Merci !

Je ne suis pas super fan des exemples sur les widgets. Essentiellement parce que nous sommes dans un cas de base commune. De fait dans ces cas là j'ai un red flag qui se lève et je tends à me méfier pour utiliser le MI.
Avec deux sources différentes, je n'ai plus aucun scrupule. Mais il est vrai que l'on rejoint là les politiques (mais sans l'aspect template)(mince j'ai oublié le nom donné aux classes à destructeur protégé non-virtuel dans le C++CS de Sutter&Alexandrescu, ce n'était pas "politique" il me semble, mais autre chose)

En ordre d'importance, je place comme Loic le NVI parmi l'argument principal. Les politiques viennent ensuite.

Je serai revenu sur le LSP dans la partie sur les problèmes : Pour que le MI marche, il faut a minima comprendre et respecter le LSP sur chaque axe d'héritage. Quand on commence à tout mélanger, c'est là que l'on ne s'en sort plus. Et le gros problème du MI, c'est souvent que l'héritage simple n'était pas compris. Comment étendre sereinement à plus d'une classe sous de telles conditions ?

Bonjour,

C'est un article très intéressant qui réveille quelques interrogations que je me pose quant à la mise en œuvre de l'héritage multiple.

Dans l'exemple 3-A (où il manque la déclaration d'héritage au passage), on définit que B est un A et que C est un A. Mais D qui est un B et un C n'est pas "un" A, il multiplie les qualités de A. Cela me semble contre intuitif.

Ainsi, j'ai le sentiment que l'héritage en losange est le résultat naturellement attendu quand on hérite plusieurs fois d'une même classe. Or ce n'est pas le comportement par défaut.

De plus, comme la qualité de l'héritage de A est définit au niveau de B et C, j'ai l'impression qu'aucun type d'héritage n'est satisfaisant. Par exemple, à supposer que j'écrive une bibliothèque où A, B et C sont définies sans héritage virtuel et qu'un utilisateur de ma bibliothèque définisse un D héritant de B et C. Il se retrouve dans l'impossibilité de choisir un héritage en losange. Du coup, lors d'un appel à une fonction de la bibliothèque prenant un A, il devra choisir s'il s'agit du A de B ou du A de C.

Alors quel comportement adopter en pratique pour ne pas bloquer les futurs développeurs ni les évolutions du logiciel ? Faut-il tout mettre en héritage virtuel ?

@j-jorge: Si il n'y a pas d'héritage virtuel, alors en effet un D n'est pas un A (tu peux tester, une instance de D ne peux pas être donné là où un A est attendu, LSP). Pourquoi la relation "est un" serait toujours transitive ?

Citation:

---

Ainsi, j'ai le sentiment que l'héritage en losange est le résultat naturellement attendu quand on hérite plusieurs fois d'une même classe. Or ce n'est pas le comportement par défaut.

---

Suivant les idiomes du C++, je ne trouve pas que ce soit un résultat naturellement attendu. Habituellement le C++ manipule tout par valeur, ce qui sous entends qu'un agregat de deux types, quels que soient leur relations, est équivalent (moyennant agencements mémoire) à deux objets de ces deux types "collés ensembles" du point de vue de la mémoire. Or ce principe ignore totalement le fait que les deux types pourraient avoir une base commune qui est donc répétée pour chaque type parcequ'ils ont chacun un état séparé.

Du coup, la solution de l'héritage virtuel m'apparait comme une exception parceque contrairement aux idiomes habituels du C++, cette feature permet de dire explicitement au language qu'on sait qu'il y a une relation entre les types et qu'on veut que leurs états soient partagés.

Je ne sais pas pour vous, mais il m'est arrivé rarement d'avoir recours à l'héritage virtuel, pour une hierarchie bien précise. Du coup j'ai plutot tendance à penser que c'est cela l'exception, et que l'heritage multilpe tout court est juste plus facile à penser par défaut.

En fait, je me dit qu'il n'y a que dans des cas de hierarchies prédéfinies et fixes (c'est à dire qui n'est pas fait pour être étendu) que c'est vraiment utile. Mais j'imagine que je manque de pratique dans le sujet.

Citation:

---

Je ne sais pas pour vous, mais il m'est arrivé rarement d'avoir recours à l'héritage virtuel, pour une hierarchie bien précise. Du coup j'ai plutot tendance à penser que c'est cela l'exception, et que l'heritage multilpe tout court est juste plus facile à penser par défaut.

---

En général, si tu as de l’héritage en losange, c’est parce que tu as un super objet. Comme en C++ on essaie d’éviter de recourir à des super objets, le cas est forcément peu fréquent.

Citation:

---

Envoyé par white_tentacle

En général, si tu as de l’héritage en losange, c’est parce que tu as un super objet. Comme en C++ on essaie d’éviter de recourir à des super objets, le cas est forcément peu fréquent.

---

C'est pas bête. Je n'utilises que rarement les super objets...

L'autre cas où j'ai du jongler avec l'héritage virtuel c'était pour faire une sorte de mixin sur deux axes pour définir des "interpolations"... mais c'était un peu overkill j'imagine : http://www.ogre3d.org/forums/viewtop...44879&p=308589

Merci pour cet article.
C'est très clair et enrichissant.

Je trouve la partie 1 & 2 bien. Par contre la 3ème partie c'est du survol et je trouve ça dommage.

On explique pas réellement comment fonctionne l'héritage virtuel et quel est le coût de son utilisation (j'aimerais bien le savoir).

Je trouve la partie sur le cast trop rapide. Il manque une schématisation d'une classe mono héritage versus multi héritage pour bien comprendre l'histoire de décalage du pointeur lors du cast.

Après un rappel sur la RTTI n'aurait pas été de refus quand on en arrive au dynamic_cast.

Il y a une erreur dans l'exemple : 3-A.

Mais merci pour cette article.

Citation:

---

Envoyé par Drannor

Je trouve la partie sur le cast trop rapide. Il manque une schématisation d'une classe mono héritage versus multi héritage pour bien comprendre l'histoire de décalage du pointeur lors du cast.

Après un rappel sur la RTTI n'aurait pas été de refus quand on en arrive au dynamic_cast.

---

surtout que le dynamic_cast ne compile pas sur cet exemple, puisque pour utiliser le dynamic_cast il faut une table de méthode virtuelle (c'est la qu'on stocke l'info RTTI)

Citation:

---

Envoyé par Drannor

On explique pas réellement comment fonctionne l'héritage virtuel et quel est le coût de son utilisation (j'aimerais bien le savoir).

---

Peut être parce que c'est un détail d'implémentation et que ça varie d'un compilateur (voire d'une version/option de compil/code particulier) à l'autre?
En général, entre un héritage simple et un héritage multiple, on ne fait que cumuler les vtable, et, en bonus, en cas d'héritage virtuel, on rajoute un offset (soit dans la vtable avec gcc, soit à part dans VC si ma mémoire est bonne). Dynamiquement, le cross cast peut aussi être impacté (toujours avec de l'héritage virtuel). Mais, voilà. A quoi cela peut servir d'avoir ce coût ?

Citation:

---

Envoyé par 3DArchi

A quoi cela peut servir d'avoir ce coût ?

---

Connaître comment une fonctionnalité est implémentée permet de comprendre l'impact sur les performances (exécution & mémoire) que cela peu avoir surtout quand on fait du temps réel embarqué comme c'est mon cas.

Citation:

---

Envoyé par Drannor

Connaître comment une fonctionnalité est implémentée permet de comprendre l'impact sur les performances (exécution & mémoire) que cela peu avoir surtout quand on fait du temps réel embarqué comme c'est mon cas.

---

Sans contexte, connaitre l'implémentation est intéressant. Cependant, ces aspects de coûts restent pour moi un faut débat (ou une illusion) : quel est le coût amené par le langage versus quel est le coût amené par la complexité du projet et son design ? AMHA, le principal contributeur en empreinte mémoire/temps d'exécution se situe entre le clavier et la chaise, pas sur les features du langage utilisé.

Citation:

---

Envoyé par Drannor

Connaître comment une fonctionnalité est implémentée permet de comprendre l'impact sur les performances (exécution & mémoire) que cela peu avoir surtout quand on fait du temps réel embarqué comme c'est mon cas.

---

Je conçois très bien que cela soit intéressant. Mais je ne pense pas que cela doive faire partie d'un document sur le C++ comme celui dont il est question ici.

Dans tout les cas je ne vois pas comment il est possible de décrire l'implémentation et l'impact de cette fonctionnalité hors de tout contexte. Dans le cadre d'une implémentation particulière, oui. Dans le cadre d'un exemple de ce qui pourrait être fait, oui. Mais dans un cadre générique, non.

En c#, certaines extensions récentes au langage disponibles avec Visual studio permettent la vérification statique.

voir ce lien , pour un bout de code très proche de celui de l'article.
http://devjourney.com/blog/code-cont...nd-interfaces/

la solution que je préfère est celle de D, que je trouve très élégante

Code:

---

1 2 3 4 5 6 7 8

interface I { int foo(int i) in { assert(i > 7); } out (result) { assert(result & 1); }   void bar(); }

---

Pour la programmation par policy, Alexandrescu lui même a fait une belle réponse sur le forum D:
En substance, il faut distinguer le but du moyen, ie faire varier facilement l'implémentation en la paramétrant, du moyen en C++ , l’héritage multiple, qui permet d'injecter du code. Il suggère d'autres approches plus naturelle en D.
http://www.digitalmars.com/d/archive..._D_130402.html

L'héritage multiple est très puissant, mais j'essaie de minimiser son utilisation . L’expérience du c# m'a apporté au contraire une discipline supplémentaire.

Pour la duplication de code dans ce dernier. C'est vrai c'est inévitable dans certains cas. Même si c'est les méthodes d'extension associées aux interfaces(mixin) permettent de limiter ce travers du langage. Cette approche est décriée, mais elle permet d'arriver à la même injection de code que l'héritage multiple; Permettre de d'écrire du code statique dans l'interface, aurait donner un surcroit d'élégance à cette technique.

Citation:

---

Envoyé par j-jorge

Dans l'exemple 3-A (où il manque la déclaration d'héritage au passage)

---

Citation:

---

Envoyé par Drannor

Il y a une erreur dans l'exemple : 3-A.

---

Citation:

---

Envoyé par screetch

surtout que le dynamic_cast ne compile pas sur cet exemple, puisque pour utiliser le dynamic_cast il faut une table de méthode virtuelle (c'est la qu'on stocke l'info RTTI)

---

Merci à vous, je viens de faire une mise à jour pour corriger ça

Citation:

---

Envoyé par j-jorge

De plus, comme la qualité de l'héritage de A est définit au niveau de B et C, j'ai l'impression qu'aucun type d'héritage n'est satisfaisant. Par exemple, à supposer que j'écrive une bibliothèque où A, B et C sont définies sans héritage virtuel et qu'un utilisateur de ma bibliothèque définisse un D héritant de B et C. Il se retrouve dans l'impossibilité de choisir un héritage en losange. Du coup, lors d'un appel à une fonction de la bibliothèque prenant un A, il devra choisir s'il s'agit du A de B ou du A de C.

Alors quel comportement adopter en pratique pour ne pas bloquer les futurs développeurs ni les évolutions du logiciel ? Faut-il tout mettre en héritage virtuel ?

---

C'est en effet un problème. Mais je ne l'ai pas encore rencontré en pratique (peut-être parce qu'on a moins l'occasion d'utiliser des interfaces que dans d'autres langages, grâce au duck typing ?). Et comme l'héritage virtuel apporte aussi ses problèmes, je ne l'utilise pas de manière préventive partout.

Citation:

---

Envoyé par PhilIvey

En c#, certaines extensions récentes au langage disponibles avec Visual studio permettent la vérification statique.

voir ce lien , pour un bout de code très proche de celui de l'article.
http://devjourney.com/blog/code-cont...nd-interfaces/

---

C'est en effet à ce mécanisme que je faisais allusion à la fin de mon 2.A.
Il y a quelques aspects sympas dans ce mécanisme (la vérification statique, qui ne marche bien évidemment que pour ce qui est vérifiable statiquement, je ne sais pas trop ce que ça donne en pratique) et d'autres aspects que j'aime moins (les possibilités de dérivation qui violent le LSP, le fait de devoir passer par une classe dédiée pour définir le contrat d'une interface, les contraintes sur la compilation...).

Et surtout, il a fallu attendre une extension du langage pour pouvoir avoir ça. Je n'ai pas encore d'opinions claire sur le fait que la programmation par contrat devrait ou pas être directement et explicitement supportée par un langage de programmation. Il y a des arguments dans les deux sens. Par contre, j'apprécie qu'un langage où elle ne l'est pas soit assez souple pour permettre de la mettre en place quand même, à partir des fonctionnalités de base du langage.

Citation:

---

Envoyé par PhilIvey

la solution que je préfère est celle de D, que je trouve très élégante

---

Je ne connais pas assez D pour commenter. Regarder D plus en détails fait partie de ma TODO list quand les journées feront 36h :)

Une petite précision pour le dynamic_cast: il n'est pas forcément nécessaire de le faire intervenir ici, puisqu'un static_cast va effectuer la même opération (un décalage de pointeur)
la différence entre static_cast et dynamic_cast dans ce cas, c'est la vérification de type (au cas ou on a une table de méthode virtuelle)
static_cast peut convertir les pointeurs aussi (pour peu qu'ils soient liés entre eux) mais il va se contenter de faire ce qu'on lui dit sans vérifier si le type dynamique de l'objet est bon ou pas.
un cast C est (très) pervers; si le compilateur connait les types, un c-cast va marcher. Si les types ne sont pas connus a la compilation lors du cast (ce qui peut arriver si on predeclare les classes) alors il va effectuer une mavaise operation (sans le decalage de pointeur)

Citation:

---

Envoyé par PhilIvey

En c#, certaines extensions récentes au langage disponibles avec Visual studio permettent la vérification statique.

voir ce lien , pour un bout de code très proche de celui de l'article.
http://devjourney.com/blog/code-cont...nd-interfaces/

la solution que je préfère est celle de D, que je trouve très élégante

Code:

---

1 2 3 4 5 6 7 8

interface I { int foo(int i) in { assert(i > 7); } out (result) { assert(result & 1); }   void bar(); }

---

Pour la programmation par policy, Alexandrescu lui même a fait une belle réponse sur le forum D:
En substance, il faut distinguer le but du moyen, ie faire varier facilement l'implémentation en la paramétrant, du moyen en C++ , l’héritage multiple, qui permet d'injecter du code. Il suggère d'autres approches plus naturelle en D.
http://www.digitalmars.com/d/archive..._D_130402.html

L'héritage multiple est très puissant, mais j'essaie de minimiser son utilisation . L’expérience du c# m'a apporté au contraire une discipline supplémentaire.

Pour la duplication de code dans ce dernier. C'est vrai c'est inévitable dans certains cas. Même si c'est les méthodes d'extension associées aux interfaces(mixin) permettent de limiter ce travers du langage. Cette approche est décriée, mais elle permet d'arriver à la même injection de code que l'héritage multiple; Permettre de d'écrire du code statique dans l'interface, aurait donner un surcroit d'élégance à cette technique.

---

J'ai noté aussi pour ma part, depuis que je me suis mis à D, une nette diminution de l'utilisation de l'héritage (par rapport à C++). On ne dérive que lorsqu'on a vraiment besoin de créer un sous-type. Dès lors, l'absence d'héritage multiple dans le langage ne se fait pas vraiment sentir.

Je réagis avec retard. :aie:

Je suis un ancien programmeur C, Pascal, C++, JAVA et maintenant plutôt C#.

Je ne suis absolument pas convaincu par les exemples montrant les limitations de l'héritage multiple d'interfaces.

La programmation par contrat a été ajoutée au Framework4 de .NET donnant beaucoup moins de travail au développeur lamda.
Et même bien avant ce Framework4, et pour des utilisations plus complexe et plus paramétrables, l'utilisation des mécanismes d'interception, ou encore mieux de "Policy Injection", fournis par un IoC container type Unity ou Spring.Net pour .NET et Spring pour JAVA permet d'avoir des choses bien plus puissante, plus concise, plus paramétrable et plus élégante que le pattern NVI.

Pour l'héritage d'implémentation, de nouveau un IoC container permet de mettre en place une composition d'objet par configuration ou par code d'initialisation très simplement rendant cet héritage surfait.

Pour la mise en place de Politique, là aussi un IoC container permette de faire pareil et c'est configurable par modification de fichier de configuration (cool pour le mocking donc la testabilité :aie:)

Un langage ne se réduit pas à sa grammaire met il faut prendre en compte tout un écosystème que ce langage draine et que sa grammaire, ses principes, son architecture permet de fabriquer.

Merci pour ce document objectif sur les problèmes de l'héritage multiple, je pourrait m'en servir comme référence pour indiquer pourquoi l'héritage multiple est dangereux sans qu'il y est des suspicions de querelle de chapelle. :ccool:

Citation:

---

Envoyé par bacelar

La programmation par contrat a été ajoutée au Framework4 de .NET donnant beaucoup moins de travail au développeur lamda.

---

Au final, la fonctionnalité est enfin là, mais elle a du passer par une modification du compilateur pour y parvenir. Je suis assez circonspect par les fonctionnalités offertes pour qu'un programme modifie son propre compilateur. J'ai peur que ça puisse devenir très vite peu maîtrisable. Mais je manque d'expérience sur le sujet.

Citation:

---

Envoyé par bacelar

Et même bien avant ce Framework4, et pour des utilisations plus complexe et plus paramétrables, l'utilisation des mécanismes d'interception, ou encore mieux de "Policy Injection", fournis par un IoC container type Unity ou Spring.Net pour .NET et Spring pour JAVA permet d'avoir des choses bien plus puissante, plus concise, plus paramétrable et plus élégante que le pattern NVI.

---

Est-ce que tu pourrais détailler ces mécanismes ? Je pensais avoir compris ce qu'était les mécanismes de type IoC, mais j'avoue que je vois mal en quoi ça peut servir ici. Les mécanismes d'interception, je ne vois pas trop à quoi ça fait allusion. Est-ce que ça concerne les modifications du compilateur que j'évoquais ?

Citation:

---

Envoyé par bacelar

Pour l'héritage d'implémentation, de nouveau un IoC container permet de mettre en place une composition d'objet par configuration ou par code d'initialisation très simplement rendant cet héritage surfait.

Pour la mise en place de Politique, là aussi un IoC container permette de faire pareil et c'est configurable par modification de fichier de configuration (cool pour le mocking donc la testabilité :aie:)

---

Idem.

Citation:

---

Envoyé par bacelar

Merci pour ce document objectif sur les problèmes de l'héritage multiple, je pourrait m'en servir comme référence pour indiquer pourquoi l'héritage multiple est dangereux sans qu'il y est des suspicions de querelle de chapelle. :ccool:

---

C'est bas comme coup ! ;)

Il te reste néanmoins à montrer que les mécanismes que tu proposes à la place n'incluent pas encore plus de problèmes que l'héritage multiple...

Citation:

---

Envoyé par JolyLoic

En effet, je ne pense pas qu'UML permette d'exprimer cette notion, et mes diagrammes ne sont donc probablement pas des diagrammes UML standards. Encore un exemple qui démontre que malgré ses désirs d'universalité, UML a été pensé avec certains types de langages en tête, et ne permet pas vraiment de représenter toutes les notions de tous les langages.

---

Rien ne t'empêche de stéréotyper les héritages de <virtual>.

A partir du moment où il s'agit d'un diagramme de conception/implémentation, et que donc le langage de programmation à ce stade est connu, il n'y a aucune ambiguïté à mon sens de le faire et exprime clairement la notion de non duplication (si j'ai bien compris) que tu souhaites mettre en avant.


L'article est très intéressant sur plusieurs aspects bien que n'étant pas un pratiquant de ce langage et un adepte de l'héritage multiple en programmation à contrario de l'héritage multiple en conceptualisation. Ce que je veux dire c'est qu'en conceptualisation, j'aurais tendance à trouver suffisant ton premier diagramme en 2B (beaucoup plus clair)et je ne ferais pas le second diagramme du 2B par contre il correspondrait à une implémentation. Dans cet exemple, je reste aussi assez septique et sur ma faim sur ta conclusion sur la souplesse bien que je reconnais que le design est plus complexe.

Il me semble aussi que dans ton second diagramme en 2B, il manque un lien pour montrer que DashBoardElementImplementation <implémente> IDashBoardElement.

Up.

Merci pour ce bon article.

J'approuve l'argument du NVI pour pouvoir tester des préconditions, des postconditions et écrire dans un fichier de log.
J'approuve aussi l'exemple avec l'IHM.

Par contre, je ne suis pas d'accord sur la pertinence de l'héritage multiple dans l'exemple avec les classes de politiques, où Tree dérive publiquement de ses classes de politique (Comparator, AllocationPolicy et BalancingPolicy).
Le problème, c'est que tout ce qui se trouve en visibilité publique dans les classes de politique vient polluer la partie publique de l'interface de Tree.
Pour offrir à l'utilisateur de la flexibilité à l'exécution, la solution qui me semble la plus propre serait que la classe Tree ait un constructeur qui prenne en paramètre ses classes de politique par référence constante :

Code:

---

1 2 3

explicit Tree(const Comparator& comp = Comparator(), const AllocationPolicy& alloc = AllocationPolicy(), const BalancingPolicy& balan = BalancingPolicy());

---

D'ailleurs, c'est ce que fait std::set :

Code:

---

1 2	explicit set(const key_compare& comp = key_compare(), const allocator_type& alloc = allocator_type());

---

Par exemple, admettons que je veuille avoir un ensemble ordonné d'entiers dont l'ordre, croissant ou décroissant, sera déterminé non pas à la compilation mais à l'exécution.
Avec std::set, je peux faire ceci :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23

template<class T> class OrdreCroissantOuDecroissant { private: bool m_croissant; public: explicit OrdreCroissantOuDecroissant(bool croissant) : m_croissant(croissant) {} bool operator() (const T& x, const T& y) const { return m_croissant && x < y || !m_croissant && y < x; } };   int _tmain(int argc, _TCHAR* argv[]) { const bool croissant = rand() % 2 == 0; const OrdreCroissantOuDecroissant<int> comp(croissant); std::set<int, OrdreCroissantOuDecroissant<int>> entiers(comp); entiers.insert(1); entiers.insert(2); entiers.insert(3); for(auto it = entiers.begin(); it != entiers.end(); ++it) std::cout << *it; return 0; }

---

Pour revenir à Tree, si on veut vraiment autoriser l'utilisateur à modifier l'allocateur alors que l'objet Tree est déjà construit, à ses risques et périls, on peut toujours lui fournir des fonctions :

Code:

---

1 2	AllocationPolicy getAllocationPolicy() const; void setAllocationPolicy(const AllocationPolicy& alloc);

---