B2 descendant de B est-elle amie de A ? A priori ce n'est pas le cas...
ais-je un moyen de contourner ?
Dans mon cas particulier j'ai plus sp=E9cifiquement
virtual B::foo()=3D0;
puis
virtual B2::foo(){...randonne allegrement dans les parties private de
A}
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Jean-Marc Desperrier
meow wrote:
Bonjour,
class A { friend class B; }
class B2 : public B;
B2 descendant de B est-elle amie de A ? A priori ce n'est pas le cas... ais-je un moyen de contourner ?
Faire une fonction protected de B qui offre un accès direct aux éléments privés de A auxquels tu souhaite que les descendants de B aient aussi accès ?
Je ne me lance pas dans les commentaires sur le fait que ressentir le besoin de faire ce genre de chose est en général révélateur d'un problème au niveau de la conception :-)
meow wrote:
Bonjour,
class A {
friend class B;
}
class B2 : public B;
B2 descendant de B est-elle amie de A ? A priori ce n'est pas le cas...
ais-je un moyen de contourner ?
Faire une fonction protected de B qui offre un accès direct aux éléments
privés de A auxquels tu souhaite que les descendants de B aient aussi
accès ?
Je ne me lance pas dans les commentaires sur le fait que ressentir le
besoin de faire ce genre de chose est en général révélateur d'un
problème au niveau de la conception :-)
B2 descendant de B est-elle amie de A ? A priori ce n'est pas le cas... ais-je un moyen de contourner ?
Faire une fonction protected de B qui offre un accès direct aux éléments privés de A auxquels tu souhaite que les descendants de B aient aussi accès ?
Je ne me lance pas dans les commentaires sur le fait que ressentir le besoin de faire ce genre de chose est en général révélateur d'un problème au niveau de la conception :-)
Fabien LE LEZ
On 12 Dec 2006 08:23:10 -0800, "meow" :
class A { friend class B; }
class B2 : public B;
B2 descendant de B est-elle amie de A ?
Quand une classe A déclare une classe B amie, elle dit "Je connais B, je sais que ses fonctions ne feront rien de mal à mes données, je peux donc lui donner accès à ma cuisine interne."
Déclarer amie une classe qu'on ne connait pas (ici, B2) n'a donc aucun sens.
virtual B2::foo(){...randonne allegrement dans les parties private de A}
AMHA, c'est un problème de design. (J'aurais presque tendance à dire qu'utiliser le mot "friend" indique d'emblée un problème de design...)
On 12 Dec 2006 08:23:10 -0800, "meow" <schwarz.ben@gmail.com>:
class A {
friend class B;
}
class B2 : public B;
B2 descendant de B est-elle amie de A ?
Quand une classe A déclare une classe B amie, elle dit "Je connais B,
je sais que ses fonctions ne feront rien de mal à mes données, je peux
donc lui donner accès à ma cuisine interne."
Déclarer amie une classe qu'on ne connait pas (ici, B2) n'a donc aucun
sens.
virtual B2::foo(){...randonne allegrement dans les parties private de
A}
AMHA, c'est un problème de design.
(J'aurais presque tendance à dire qu'utiliser le mot "friend" indique
d'emblée un problème de design...)
Quand une classe A déclare une classe B amie, elle dit "Je connais B, je sais que ses fonctions ne feront rien de mal à mes données, je peux donc lui donner accès à ma cuisine interne."
Déclarer amie une classe qu'on ne connait pas (ici, B2) n'a donc aucun sens.
virtual B2::foo(){...randonne allegrement dans les parties private de A}
AMHA, c'est un problème de design. (J'aurais presque tendance à dire qu'utiliser le mot "friend" indique d'emblée un problème de design...)
Loïc Joly
(J'aurais presque tendance à dire qu'utiliser le mot "friend" indique d'emblée un problème de design...)
Je suis assez peu d'accord avec cette phrase. friend est un mot qui permet d'augmenter l'encapsulation d'une classe, et en ce sens, je n'ai aucun scrupule à l'utiliser quand j'en ai besoin.
-- Loïc
(J'aurais presque tendance à dire qu'utiliser le mot "friend" indique
d'emblée un problème de design...)
Je suis assez peu d'accord avec cette phrase. friend est un mot qui
permet d'augmenter l'encapsulation d'une classe, et en ce sens, je n'ai
aucun scrupule à l'utiliser quand j'en ai besoin.
(J'aurais presque tendance à dire qu'utiliser le mot "friend" indique d'emblée un problème de design...)
Je suis assez peu d'accord avec cette phrase. friend est un mot qui permet d'augmenter l'encapsulation d'une classe, et en ce sens, je n'ai aucun scrupule à l'utiliser quand j'en ai besoin.
-- Loïc
James Kanze
Fabien LE LEZ wrote:
On 12 Dec 2006 08:23:10 -0800, "meow" :
class A { friend class B; }
class B2 : public B;
B2 descendant de B est-elle amie de A ?
Quand une classe A déclare une classe B amie, elle dit "Je connais B, je sais que ses fonctions ne feront rien de mal à mes données, je peux donc lui donner accès à ma cuisine interne."
Je dirais même plus : en déclarant B ami d'A, l'auteur d'A dit que B fait partie de l'abstraction d'A, qu'on ne pourrait pas faire évoluer A sans faire évoluer B, et vice versa.
Déclarer amie une classe qu'on ne connait pas (ici, B2) n'a donc aucun sens.
virtual B2::foo(){...randonne allegrement dans les parties private de A}
AMHA, c'est un problème de design. (J'aurais presque tendance à dire qu'utiliser le mot "friend" indique d'emblée un problème de design...)
Pas d'accord. Il y a des abstractions qui comporte plusieurs classes, ou une classe est des fonctions libres. N'oublie pas que « class » (comme tout élément du langage, d'ailleurs) est d'un certain sens un détail de l'implémentation. C'est un moyen technique d'implémenter ta conception. Or, s'il est fréquent qu'un « objet » (au sens OO) se mappe à une « class » au niveau de son implémentation, ce n'est pas obligatoire.
-- James Kanze (GABI Software) email: Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Fabien LE LEZ wrote:
On 12 Dec 2006 08:23:10 -0800, "meow" <schwarz.ben@gmail.com>:
class A {
friend class B;
}
class B2 : public B;
B2 descendant de B est-elle amie de A ?
Quand une classe A déclare une classe B amie, elle dit "Je connais B,
je sais que ses fonctions ne feront rien de mal à mes données, je peux
donc lui donner accès à ma cuisine interne."
Je dirais même plus : en déclarant B ami d'A, l'auteur d'A dit
que B fait partie de l'abstraction d'A, qu'on ne pourrait pas
faire évoluer A sans faire évoluer B, et vice versa.
Déclarer amie une classe qu'on ne connait pas (ici, B2) n'a donc aucun
sens.
virtual B2::foo(){...randonne allegrement dans les parties private de
A}
AMHA, c'est un problème de design.
(J'aurais presque tendance à dire qu'utiliser le mot "friend" indique
d'emblée un problème de design...)
Pas d'accord. Il y a des abstractions qui comporte plusieurs
classes, ou une classe est des fonctions libres. N'oublie pas
que « class » (comme tout élément du langage, d'ailleurs) est
d'un certain sens un détail de l'implémentation. C'est un moyen
technique d'implémenter ta conception. Or, s'il est fréquent
qu'un « objet » (au sens OO) se mappe à une « class » au
niveau de son implémentation, ce n'est pas obligatoire.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Quand une classe A déclare une classe B amie, elle dit "Je connais B, je sais que ses fonctions ne feront rien de mal à mes données, je peux donc lui donner accès à ma cuisine interne."
Je dirais même plus : en déclarant B ami d'A, l'auteur d'A dit que B fait partie de l'abstraction d'A, qu'on ne pourrait pas faire évoluer A sans faire évoluer B, et vice versa.
Déclarer amie une classe qu'on ne connait pas (ici, B2) n'a donc aucun sens.
virtual B2::foo(){...randonne allegrement dans les parties private de A}
AMHA, c'est un problème de design. (J'aurais presque tendance à dire qu'utiliser le mot "friend" indique d'emblée un problème de design...)
Pas d'accord. Il y a des abstractions qui comporte plusieurs classes, ou une classe est des fonctions libres. N'oublie pas que « class » (comme tout élément du langage, d'ailleurs) est d'un certain sens un détail de l'implémentation. C'est un moyen technique d'implémenter ta conception. Or, s'il est fréquent qu'un « objet » (au sens OO) se mappe à une « class » au niveau de son implémentation, ce n'est pas obligatoire.
-- James Kanze (GABI Software) email: Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
meow
Faire une fonction protected de B qui offre un accès direct aux élé ments privés de A auxquels tu souhaite que les descendants de B aient aussi accès ?
C'est plus ou moins ce que j'ai fait.
Je ne me lance pas dans les commentaires sur le fait que ressentir le besoin de faire ce genre de chose est en général révélateur d'un problème au niveau de la conception :-)
Oui, j'ai un problème de design : je débute en C++ depuis 2 ans et je continue d'entasser mes ordures sur un pseudo-design réalisé au début de ma thèse :) Et comme malheureusement ma thèse ne concerne pas le design, je ne prends que rarement le temps de corriger le design global de mon tas d'ordure :) En l'occurrence j'ai voulu planquer un tas d'objets "gores" dans une classe A qui s'est retrouvée à faire la vaisselle et le café, tout ça parce que je voulais empecher l'utilisateur de faire des choses incohérente... Au fur et à mesure je me rends bien compte que finalement la cohérence n'est qu'une histoire de point de vue...
Pour en revenir au sujet du fil, si je vous enten bien : "il n'y a pas moyen de déclarer une hiérarchie amie d'une autre."
Faire une fonction protected de B qui offre un accès direct aux élé ments
privés de A auxquels tu souhaite que les descendants de B aient aussi
accès ?
C'est plus ou moins ce que j'ai fait.
Je ne me lance pas dans les commentaires sur le fait que ressentir le
besoin de faire ce genre de chose est en général révélateur d'un
problème au niveau de la conception :-)
Oui, j'ai un problème de design : je débute en C++ depuis 2 ans et je
continue d'entasser mes ordures sur un pseudo-design réalisé au
début de ma thèse :)
Et comme malheureusement ma thèse ne concerne pas le design, je ne
prends que rarement le temps de corriger le design global de mon tas
d'ordure :)
En l'occurrence j'ai voulu planquer un tas d'objets "gores" dans une
classe A qui s'est retrouvée à faire la vaisselle et le café, tout
ça parce que je voulais empecher l'utilisateur de faire des choses
incohérente... Au fur et à mesure je me rends bien compte que
finalement la cohérence n'est qu'une histoire de point de vue...
Pour en revenir au sujet du fil, si je vous enten bien : "il n'y a pas
moyen de déclarer une hiérarchie amie d'une autre."
Faire une fonction protected de B qui offre un accès direct aux élé ments privés de A auxquels tu souhaite que les descendants de B aient aussi accès ?
C'est plus ou moins ce que j'ai fait.
Je ne me lance pas dans les commentaires sur le fait que ressentir le besoin de faire ce genre de chose est en général révélateur d'un problème au niveau de la conception :-)
Oui, j'ai un problème de design : je débute en C++ depuis 2 ans et je continue d'entasser mes ordures sur un pseudo-design réalisé au début de ma thèse :) Et comme malheureusement ma thèse ne concerne pas le design, je ne prends que rarement le temps de corriger le design global de mon tas d'ordure :) En l'occurrence j'ai voulu planquer un tas d'objets "gores" dans une classe A qui s'est retrouvée à faire la vaisselle et le café, tout ça parce que je voulais empecher l'utilisateur de faire des choses incohérente... Au fur et à mesure je me rends bien compte que finalement la cohérence n'est qu'une histoire de point de vue...
Pour en revenir au sujet du fil, si je vous enten bien : "il n'y a pas moyen de déclarer une hiérarchie amie d'une autre."
