La classe A peut-elle interdire à ses classes filles l'accès à une
méthode particulière.
Je recherche une solution bcp + élégante que celle-ci :
les classes héritières ont une propriété héritée de A qui est à vrai par
ex quand l'objet est de classe A et à faux quand l'objet est de classe B.
Tout appel à ladite méthode vérifie l'état de cette propriété avant tout
traitement..
Certes mais j'avais oublié une info (Méa Culpa) : je n'ai pas accès au code source de la classe mère .
Et ne pas compter sur l'utilisateur pour tester si l'objet est une instance de telle ou telle classe.
Ca fait bcp de contraintes mais si qqun a une solution ..
Serge Paccalin
Le vendredi 19 septembre 2003 à 15:49, charly a écrit dans fr.comp.lang.c++ :
Certes mais j'avais oublié une info (Méa Culpa) : je n'ai pas accès au code source de la classe mère .
Et ne pas compter sur l'utilisateur pour tester si l'objet est une instance de telle ou telle classe.
Ca fait bcp de contraintes mais si qqun a une solution ..
Peut-être en intercalant un étage : une classe A' dérivant de A, dont doivent dériver les classes B...
class A { public: int autorisee(); int interdite(); };
class Abis : private A { public: int autorisee() { return A::autorisee(); } };
class B : public Abis { // N'a pas accès à A::interdite. };
-- ___________ 2003-09-19 16:42:12 _/ _ _`_`_`_) Serge PACCALIN -- sp ad mailclub.net _L_) Il faut donc que les hommes commencent -'(__) par n'être pas fanatiques pour mériter _/___(_) la tolérance. -- Voltaire, 1763
Le vendredi 19 septembre 2003 à 15:49, charly a écrit dans
fr.comp.lang.c++ :
Certes mais j'avais oublié une info (Méa Culpa) : je n'ai pas accès au
code source de la classe mère .
Et ne pas compter sur l'utilisateur pour tester si l'objet est une
instance de telle ou telle classe.
Ca fait bcp de contraintes mais si qqun a une solution ..
Peut-être en intercalant un étage : une classe A' dérivant de A, dont
doivent dériver les classes B...
class A
{
public:
int autorisee();
int interdite();
};
class Abis : private A
{
public:
int autorisee()
{
return A::autorisee();
}
};
class B : public Abis
{
// N'a pas accès à A::interdite.
};
--
___________ 2003-09-19 16:42:12
_/ _ _`_`_`_) Serge PACCALIN -- sp ad mailclub.net
_L_) Il faut donc que les hommes commencent
-'(__) par n'être pas fanatiques pour mériter
_/___(_) la tolérance. -- Voltaire, 1763
Le vendredi 19 septembre 2003 à 15:49, charly a écrit dans fr.comp.lang.c++ :
Certes mais j'avais oublié une info (Méa Culpa) : je n'ai pas accès au code source de la classe mère .
Et ne pas compter sur l'utilisateur pour tester si l'objet est une instance de telle ou telle classe.
Ca fait bcp de contraintes mais si qqun a une solution ..
Peut-être en intercalant un étage : une classe A' dérivant de A, dont doivent dériver les classes B...
class A { public: int autorisee(); int interdite(); };
class Abis : private A { public: int autorisee() { return A::autorisee(); } };
class B : public Abis { // N'a pas accès à A::interdite. };
-- ___________ 2003-09-19 16:42:12 _/ _ _`_`_`_) Serge PACCALIN -- sp ad mailclub.net _L_) Il faut donc que les hommes commencent -'(__) par n'être pas fanatiques pour mériter _/___(_) la tolérance. -- Voltaire, 1763
Christophe Lephay
"charly" a écrit dans le message de news:3f6b088c$0$27595$
Certes mais j'avais oublié une info (Méa Culpa) : je n'ai pas accès au code source de la classe mère .
Et ne pas compter sur l'utilisateur pour tester si l'objet est une instance de telle ou telle classe.
Ca fait bcp de contraintes mais si qqun a une solution ..
Pourquoi veux-tu que B hérite de A ?
Je pose la question, parce que rendre inaccessible une fonction membre qui est public dans la classe de base s'accorde assez mal avec l'héritage public (je suppose que tu fais un héritage public et que la fonction membre est elle-même publique).
A mon avis, tu es en train de commettre une erreur de design juste par flemme de retaper quelques fonctions (bien qu'avec aussi peu d'informations sur ton problème, il est possible que ta démarche soit justifiée).
Je te suggère de poster un peu plus d'informations...
Chris
"charly" <kanari667@yahoo.fr> a écrit dans le message de
news:3f6b088c$0$27595$626a54ce@news.free.fr...
Certes mais j'avais oublié une info (Méa Culpa) : je n'ai pas accès au
code source de la classe mère .
Et ne pas compter sur l'utilisateur pour tester si l'objet est une
instance de telle ou telle classe.
Ca fait bcp de contraintes mais si qqun a une solution ..
Pourquoi veux-tu que B hérite de A ?
Je pose la question, parce que rendre inaccessible une fonction membre qui
est public dans la classe de base s'accorde assez mal avec l'héritage public
(je suppose que tu fais un héritage public et que la fonction membre est
elle-même publique).
A mon avis, tu es en train de commettre une erreur de design juste par
flemme de retaper quelques fonctions (bien qu'avec aussi peu d'informations
sur ton problème, il est possible que ta démarche soit justifiée).
Je te suggère de poster un peu plus d'informations...
"charly" a écrit dans le message de news:3f6b088c$0$27595$
Certes mais j'avais oublié une info (Méa Culpa) : je n'ai pas accès au code source de la classe mère .
Et ne pas compter sur l'utilisateur pour tester si l'objet est une instance de telle ou telle classe.
Ca fait bcp de contraintes mais si qqun a une solution ..
Pourquoi veux-tu que B hérite de A ?
Je pose la question, parce que rendre inaccessible une fonction membre qui est public dans la classe de base s'accorde assez mal avec l'héritage public (je suppose que tu fais un héritage public et que la fonction membre est elle-même publique).
A mon avis, tu es en train de commettre une erreur de design juste par flemme de retaper quelques fonctions (bien qu'avec aussi peu d'informations sur ton problème, il est possible que ta démarche soit justifiée).
Je te suggère de poster un peu plus d'informations...
Chris
charly
Merci pour vos contributions,
En fait, La classe A n'est pas nécessairement développée par moi-même, ce qui explique que je n'ai pas la main sur le design (genre classes de bibliothèques toutes faites).
Il semblerait que la solution proposée par Serge Paccalin corresponde à nos besoins...
Bon WE à tous en tout cas et merci encore !
Merci pour vos contributions,
En fait, La classe A n'est pas nécessairement développée par moi-même,
ce qui explique que je n'ai pas la main sur le design (genre classes de
bibliothèques toutes faites).
Il semblerait que la solution proposée par Serge Paccalin corresponde à
nos besoins...
En fait, La classe A n'est pas nécessairement développée par moi-même, ce qui explique que je n'ai pas la main sur le design (genre classes de bibliothèques toutes faites).
Il semblerait que la solution proposée par Serge Paccalin corresponde à nos besoins...
Bon WE à tous en tout cas et merci encore !
Gourgouilloult
Serge Paccalin wrote:
Peut-être en intercalant un étage : une classe A' dérivant de A, dont doivent dériver les classes B...
Elle de qui, au fait, cette petite phrase "il n'y a pas de problème qu'un niveau supplémentaire d'indirection ne puisse résoudre" ?
class A { public: int autorisee(); int interdite(); };
class Abis : private A { public: int autorisee() { return A::autorisee(); } };
class B : public Abis { // N'a pas accès à A::interdite. };
Pourquoi pas plutôt une déclaration using dans Abis, pour autorisee() ?
Gourgou
Serge Paccalin wrote:
Peut-être en intercalant un étage : une classe A' dérivant de A, dont
doivent dériver les classes B...
Elle de qui, au fait, cette petite phrase "il n'y a pas de problème
qu'un niveau supplémentaire d'indirection ne puisse résoudre" ?
class A
{
public:
int autorisee();
int interdite();
};
class Abis : private A
{
public:
int autorisee()
{
return A::autorisee();
}
};
class B : public Abis
{
// N'a pas accès à A::interdite.
};
Pourquoi pas plutôt une déclaration using dans Abis, pour autorisee() ?
Peut-être en intercalant un étage : une classe A' dérivant de A, dont doivent dériver les classes B...
Elle de qui, au fait, cette petite phrase "il n'y a pas de problème qu'un niveau supplémentaire d'indirection ne puisse résoudre" ?
class A { public: int autorisee(); int interdite(); };
class Abis : private A { public: int autorisee() { return A::autorisee(); } };
class B : public Abis { // N'a pas accès à A::interdite. };
Pourquoi pas plutôt une déclaration using dans Abis, pour autorisee() ?
Gourgou
kanze
Gourgouilloult <gourgou_at_club-internet_point_fr> wrote in message news:<3f6c389b$0$20948$...
Serge Paccalin wrote:
Peut-être en intercalant un étage : une classe A' dérivant de A, dont doivent dériver les classes B...
Elle de qui, au fait, cette petite phrase "il n'y a pas de problème qu'un niveau supplémentaire d'indirection ne puisse résoudre" ?
C'était l'énoncé original. Adapté à l'OO, ça donne « il n'y a pas de problème qu'un niveau supplémentaire d'héritage ne puisse résoudre. »
-- James Kanze GABI Software mailto: Conseils en informatique orientée objet/ http://www.gabi-soft.fr Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
Gourgouilloult <gourgou_at_club-internet_point_fr> wrote in message
news:<3f6c389b$0$20948$7a628cd7@news.club-internet.fr>...
Serge Paccalin wrote:
Peut-être en intercalant un étage : une classe A' dérivant de A,
dont doivent dériver les classes B...
Elle de qui, au fait, cette petite phrase "il n'y a pas de problème
qu'un niveau supplémentaire d'indirection ne puisse résoudre" ?
C'était l'énoncé original. Adapté à l'OO, ça donne « il n'y a pas de
problème qu'un niveau supplémentaire d'héritage ne puisse résoudre. »
--
James Kanze GABI Software mailto:kanze@gabi-soft.fr
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
Gourgouilloult <gourgou_at_club-internet_point_fr> wrote in message news:<3f6c389b$0$20948$...
Serge Paccalin wrote:
Peut-être en intercalant un étage : une classe A' dérivant de A, dont doivent dériver les classes B...
Elle de qui, au fait, cette petite phrase "il n'y a pas de problème qu'un niveau supplémentaire d'indirection ne puisse résoudre" ?
C'était l'énoncé original. Adapté à l'OO, ça donne « il n'y a pas de problème qu'un niveau supplémentaire d'héritage ne puisse résoudre. »
-- James Kanze GABI Software mailto: Conseils en informatique orientée objet/ http://www.gabi-soft.fr Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
