Discussion :

[tnarol]

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

Merci

[nouknouk]

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.

[GanYoshi]

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.
Source : http://www.devx.com/tips/Tip/29062

[Davidbrcz]

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

Merci

Intérêt ?

[Ubiquité]

Intérêt ?

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

[Davidbrcz]

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.

[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.

[Davidbrcz]

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).

[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é.

[Goten]

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).

[tnarol]

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.

[GanYoshi]

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.

[Davidbrcz]

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 )

[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.

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

[Davidbrcz]

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, ....

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

[Médinoc]

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...

[screetch]

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

[Klaim]

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?

[screetch]

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.

[Lavock]

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 ).