Peut-on interdire la dérivation d'une classe ?

Je sais qu'en Java c'est possible mais en C++ ?

Merci

Pas directement, mais tu peux jouer sur les constructeurs/destructeurs 'private' pour la rendre in-héritable dans les faits.

Un article intéressant sur codeGuru.

Bonjour,

A ce que j'ai cru comprendre, il faut mettre le constructeur en private, et faire une méthode static final* CreateInstance() qui renvoit une instance de la classe. :D
Source : http://www.devx.com/tips/Tip/29062

Citation:

---

Envoyé par tnarol

Je sais qu'en Java c'est possible mais en C++ ?

Merci

---

Intérêt ?

Citation:

---

Envoyé par Davidbrcz

Intérêt ?

---

Quitte a ne pas rendre une classe efficacement derivable avec un destructeur virtuel, autant empecher clairement l'heritage.

Héritage n'équivaut pas à polymorphisme. Comment pouvez vous prévoir à l'avance ce que va devenir la classe une fois lachée dans la nature ?

Ca me ferait chier de ne pas pouvoir faire un héritage privé pour réutiliser du code à cause de ce genre de manipulations foireuses.

Si tu n'herite pas pour le polymorphisme, alors c'est plus ou moins pour forcer l'amitie avec cette classe, si ca c'est pas une manipulation foireuse... C'est clairement une faute d'un point de vue OO.

Citation:

---

Envoyé par Ubiquité

Si tu n'herite pas pour le polymorphisme, alors c'est plus ou moins pour forcer l'amitie avec cette classe, si ca c'est pas une manipulation foireuse... C'est clairement une faute d'un point de vue OO.

---

Nan, tu es dans l'optique héritage=polymorphisme (ce qui est faux).

Tu peux utiliser un héritage privé pour réutiliser du code (c'est une alternative à la composition) ou l'héritage protected (je n'ai pas d'exemple réel mais je me rappelle que Luc en avait croisé un).

F.A.Q. : Pourquoi mettre en œuvre un héritage ?

L'intérêt d'interdire l'héritage ? Forcer à la composition si on veut bénéficier de l'implémentation. Mais, j'avoue que je ne vois pas de cas immédiat d'utilité.

Citation:

---

Envoyé par 3DArchi

F.A.Q. : Pourquoi mettre en œuvre un héritage ?

L'intérêt d'interdire l'héritage ? Forcer à la composition si on veut bénéficier de l'implémentation. Mais, j'avoue que je ne vois pas de cas immédiat d'utilité.

---

Je préfére laisser le choix perso... J'ai tendance à privilégier la compositions quand je réutilise des composants quoi, mais tout le monde a pas forcément la même approche. Donc autant laisser la liberté, même si ça permet de se tirer une balle dans le pied. (ça se rapproche du dilemme des templates, ceux qui veulent restreindre à certains types).

Citation:

---

Envoyé par 3DArchi

L'intérêt d'interdire l'héritage ?

---

Je ne sais pas non plus à vrai dire. C'était une question de test professionnel à laquelle j'ai répondu que je ne voyais pas trop l'intérêt et que la seule manière que je voyais était de rendre le constructeur privé en ayant une méthode publique de construction.

Apparemment la question était un peu stupide mais je n'en était pas sûr étant donné qu'il y a un mot clé "final" fait spécialement pour ça en Java, je me suis dit qu'il pourrait y avoir une bonne raison.

Citation:

---

Envoyé par 3DArchi

F.A.Q. : Pourquoi mettre en œuvre un héritage ?

L'intérêt d'interdire l'héritage ? Forcer à la composition si on veut bénéficier de l'implémentation. Mais, j'avoue que je ne vois pas de cas immédiat d'utilité.

---

Si on veux garantir le comportement d'un élément, par exemple dans une api.
En java les objets String par exemple ne sont pas dérivable ça permet de pouvoir faire confiance au comportement d'un objet.
C'est ce que j'en ai compris.

Citation:

---

Envoyé par Herve-Loiret

Si on veux garantir le comportement d'un élément, par exemple dans une api.

En java les objets String par exemple ne sont pas dérivable ça permet de pouvoir faire confiance au comportement d'un objet.

C'est ce que j'en ai compris.

---

Oui mais en C++ tout est statique par défaut, alors qu'en Java tout est dynamique.

Même si tu dérives std::string (ce qui n'est pas conseillé), et que tu passes ta classe dérivée à la place d'une std::string, tu sera sûr du résultat car aucune fonction n'est virtuelle dans std::string, ca sera donc les fonctions de std::string qui seront appelées.

Le C++ offre le moyen de rendre dynamique (fonctions virtuelles) mais pas de finaliser. Le Java offre le moyen de finaliser mais pas de rendre "statique" (pas au sens fonction membre statique, au sens non-dynamique).

2 approches différentes avec chacun des cotés des arguments (je reste neutre en ne disant pas ce que je pense de Java :aie:)

Je ne suis pas sûr, mais je pense qu'il doit y avoir des cas où il peut être intéressant d'interdire l'héritage. Par exemple, lorsqu'on a d'énormes contraintes de rapidité d'exécution et de mémoire utilisée, on aime pouvoir se passer d'une vtable pour des objets simples, donc aucune fonction virtuelle, donc pas de destructeur virtuel, donc, si on veut faire ça bien, on interdit d'en hériter pour éviter toute mauvaise utilisation. D'autant plus que parfois, on sait très bien qu'une classe ne sera jamais héritée.

J'ai du mal à trouver un bon exemple, mais si des gens se sont posé la question, c'est qu'il doit y avoir une raison :)

Citation:

---

Envoyé par r0d

Je ne suis pas sûr, mais je pense qu'il doit y avoir des cas où il peut être intéressant d'interdire l'héritage. Par exemple, lorsqu'on a d'énormes contraintes de rapidité d'exécution et de mémoire utilisée, on aime pouvoir se passer d'une vtable pour des objets simples, donc aucune fonction virtuelle, donc pas de destructeur virtuel, donc, si on veut faire ça bien, on interdit d'en hériter pour éviter toute mauvaise utilisation. D'autant plus que parfois, on sait très bien qu'une classe ne sera jamais héritée.

---

Ok, mais en échange tu te mange un surcout à chaque construction, tes objets ne sont plus stockable dans un vecteur, ....

Citation:

---

Envoyé par r0d

J'ai du mal à trouver un bon exemple, mais si des gens se sont posé la question, c'est qu'il doit y avoir une raison :)

---

Pas forcément

Mais ça, c'est seulement parce qu'on n'a pas de moyen en C++ d'interdire l'héritage sans rendre le constructeur privé. S'il y avait, on pourrait interdire l'héritage sans rendre obligatoire l'allocation dynamique...

interdire la dérivation est pour moi un moyen d'interdire l'extensibilité du code par ce moyen. ca fait partie de l'API, en quelque sorte, de la facon dont il faut utiliser la bibliotheque.
c'est la raison pour laquelle j'utilise friend aussi, et que je déclare quelques classes en amies, ca veut dire que les autres classes ne sont *pas* censées utiliser cette classe. et si je souhaite que l'on ne dérive pas de cette classe, j'aimerai pouvoir le faire

Personellement, je préfère utiliser friend uniquement quand le comportement de l'instance de la classe est définie par plusieurs classes/fonctions externes.

Utiliser friend pour indiquer les classes a ne pas utiliser me semble une convention un poil fragile non?

friend sert a donner l'acces a un nombre (fini) d'autres classes, si l'utilisateur se pointe avec son code crados (j'exagere bien sur hein, mais disons qu'il veut bidouiller un truc dans l'interface) il ne peut pas car ses classes ne sont pas amies. l'acces est bien interdit.

Je suis pas trop pour ce genre d'approche. Lorsque qu'on fourni une api, on fourni aussi une doc, en mentionnant que l'héritage doit être éviter par exemple.

Mais l'interdire, ça veux aussi un peu dire : "non, je sais mieux ce qu'il faut pour toi que toi !"

Je suis d'accord pour repousser les erreur du runtime à la compilation, mais je vois pas l'intérêt d'un fournisseur d'api de repousser les erreurs de conception à la compilation...

Et la possibilité de bidouiller une interface presque bien pensée pour un problème donné, je trouve que ça fait un peux partie des charmes du C++ (contrairement à d'autre langage OO que j'apprécie moins :aie:).

Sa rejoint plus ou moins ce que j'avais dis, restons dans la philosophie du C++, si l'utilisateur veut se tirer une balle dans le pied et s'en resservir après, alors grand bien lui fasse.
Sinon on finit comme d'autre langages où on croit le développeur trop bête pour savoir développer par lui même.

L'héritage du Java est un héritage qui tire la substituabilité. Impossible d'hériter dans un but d'importation de code pur. Seule la composition remplit ce rôle en Java.

En C++, hériter publiquement d'un truc qui n'a pas été prévu pour finit toujours par introduire des problèmes. Donc on documente que la classe va par exemple avoir une sémantique de valeur (chose que Java ne sait pas supporter simplement; cf leurs prises de tête avec equals()).

En C++, la seule façon d'interdire l'héritage est de jouer avec une classe de base virtuelle. Ce qui tire une vtble. (les hacks à base de T::createIntance() sont tout pourris car ils bloquent les créations sur la pile simples, or c'est pour les classes à sémantique de valeur qu'il est important d'interdire l'héritage public)

Bref, écrire en gros : cette classe n'est pas faite pour être héritée publiquement, c'est bien.

PS: pour l'héritage protégé, j'avais lu un truc à ce sujet dans un article/blog d'un type qui bossait sur Qt.

Il me semble que cet article - qui a été signalé dès les premiers messages - est très intéressant et contient à peu près toutes les idées qui ont été émises ensuite dans ce fil (et montre aussi que certaines d'entre elles sont erronées) :
http://www.codeguru.com/cpp/cpp/cpp_...cle.php/c4143/
qu'en pensez-vous ?

En tout cas ça marche pas trop si on veut empêcher l'héritage pour des raisons de performances ou de taille.

Sinon un commentaire dans le header et un destructeur non virtuel c'est bien aussi.

Citation:

---

Envoyé par Lavock

... je vois pas l'intérêt d'un fournisseur d'api de repousser les erreurs de conception à la compilation...

---

moi c'est exactement ce que je veux faire.

Eh bien, peut-être m'étais-je enthousiasmé un peu vite à propos de l'article donné plus haut par nouknouk
http://www.codeguru.com/cpp/cpp/cpp_...cle.php/c4143/

La solution ultime proposée par l'auteur, est, si je ne me trompe :

Code:

---

1 2 3 4 5 6 7 8 9 10 11

template <typename T> class MakeFinal { private: ~MakeFinal() { }; friend T; };   class FinalClass : virtual public MakeFinal<FinalClass> { };

---

mais en définitive chez moi sous g++ ça ne compile pas :

Code:

---

1 2 3 4 5

example.cpp:6: error: a class-key must be used when declaring a friend example.cpp:6: error: friend declaration does not name a class or function

---

:(

J'avais posté un code qui marche il y a longtemps -- mais je n'ai pas réussi à le retrouver.

Ca y est. C'était là: http://www.developpez.net/forums/d42...r-descendance/

Citation:

---

Envoyé par ptyxs

Eh bien, peut-être m'étais-je enthousiasmé un peu vite à propos de l'article donné plus haut par nouknouk
http://www.codeguru.com/cpp/cpp/cpp_...cle.php/c4143/

La solution ultime proposée par l'auteur, est, si je ne me trompe :

Code:

---

1 2 3 4 5 6 7 8 9 10 11

template <typename T> class MakeFinal { private: ~MakeFinal() { }; friend T; };   class FinalClass : virtual public MakeFinal<FinalClass> { };

---

mais en définitive chez moi sous g++ ça ne compile pas :

Code:

---

1 2 3 4 5

example.cpp:6: error: a class-key must be used when declaring a friend example.cpp:6: error: friend declaration does not name a class or function

---

:(

---

As-tu essaye

Code:

---

friend class T;

---

ou encore

Code:

---

typename friend [class] T;

---

? Dans tous les cas, il faut soit n'allouer que sur le tas, soit se trainer une vtable...

Il faut attendre C++0X pour pouvoir rendre friend un parametre template.