Porté d'une fonction membre

Marc

11/12/2003 à 11:54

class A {
friend class B;
};

- Permet à B d'accéder aux données membres et méthodes privées de A
- le principe : on déclare ses amis, c'est à dire les classes (ou même
fonctions) qui peuvent accéder à la partie privée de la classe.

Ensuite tu déclares les méthodes de A que tu ne souhaites pas "publier" dans
la partie private...
Est-ce clair ?
Marc

"PurL" a écrit dans le message de news:
br9hrj$8g5$

Bonjour,

J'ai une classe A.
J'ai une classe B qui permet de gérer une liste d'objet A.
Pour cela, B doit accéder à des fonctions membres de A.
Je suis obligé de les déclarer public, mais je voudrais pas que le reste
du

programme notament la partie qui utilise B puisse y accéder.
Je voudrais qu'il n'y ait que B qui puisse y accéder...

Comment puis-je faire ?

Merci,

PurL.

PurL

11/12/2003 à 12:14

Marc wrote:

class A {
friend class B;
};

- Permet à B d'accéder aux données membres et méthodes privées de A
- le principe : on déclare ses amis, c'est à dire les classes (ou même
fonctions) qui peuvent accéder à la partie privée de la classe.

Ensuite tu déclares les méthodes de A que tu ne souhaites pas
"publier" dans la partie private...
Est-ce clair ?
Marc

Merci,

PurL

Jean-Marc Molina

11/12/2003 à 13:37

Bonjour Marc,

Ensuite tu déclares les méthodes de A que tu ne souhaites pas "publier"
dans

la partie private...

Qu'est-ce que tu entends par là ?
friend permet normalement à la classe B d'accéder à l'ensemble des attributs
et méthodes de A, non ?

Le seule problème de cette solution c'est que B a accès à tout, alors qu'il
vaudrait qu'il n'ait accès qu'aux méthodes publics de A, non ?

La seule solution que je vois c'est de créer une DLL avec A et B dedans,
seule la classe B est exportée ce qui empêche l'application d'utiliser la
classe A. Une sorte d'interface. Je ne vois pas trop comment implémenter ce
système avec un motif d'interface (classe virtuelle pure...).

JM

--
Europe > France > Lyon
Clé AntiPourriel : PASUNPOURRIEL (ne pas retirer)

Marc

11/12/2003 à 14:21

J'ai répondu à la question telle que je l'ai comprise...
Ensuite effectivement, il est possible de cacher A de plusieurs manières
(classe d'interface, etc...)
Marc

Benoit Rousseau

11/12/2003 à 14:50

Jean-Marc Molina wrote:

La seule solution que je vois c'est de créer une DLL avec A et B dedans,
Créer une quoi ?

--
--------------------------------------------
Benoît Rousseau : roussebe at spray dot se
Jouez en programmant : http://realtimebattle.sourceforge.net/

Vianney Lançon

11/12/2003 à 15:40

Le Thu, 11 Dec 2003 13:37:40 +0100, dans fr.comp.lang.c++,
Jean-Marc Molina a dit :

friend permet normalement à la classe B d'accéder à l'ensemble des attributs
et méthodes de A, non ?

Le seule problème de cette solution c'est que B a accès à tout, alors qu'il
vaudrait qu'il n'ait accès qu'aux méthodes publics de A, non ?

La seule solution que je vois c'est de créer une DLL avec A et B dedans,
seule la classe B est exportée ce qui empêche l'application d'utiliser la
classe A. Une sorte d'interface. Je ne vois pas trop comment implémenter ce
système avec un motif d'interface (classe virtuelle pure...).

Il suffit de définir des classes qui gèrent les droits d'access à la
classe A.
A a pour friend ses "Accessor". Et ces accessor ne forward qu'une
partie des fonction de A.

De ce fait en utilisant friend pour un accessor, on garantis l'accès
qu'à un nombre limité de fonctions.

Il suffit ensuite de mettre toutes les fonctions de A en private.

Dans l'exemple suivant B n'a accès qu'à callPrivateA(1|2|3) mais
pas à callPrivateA(4|5|6).

class A
{
public:
class Accessor123
{
friend class B;
public:
explicit Accessor123(A& a):m_a(a){}
private:
void callPrivateA1();
void callPrivateA2();
void callPrivateA3();
private:
A& m_a;
};

class Accessor456
{
public:
explicit Accessor456(A& a):m_a(a){}
private:
void callPrivateA4();
void callPrivateA5();
void callPrivateA6();
private:
A& m_a;
};

friend class Accessor123;
friend class Accessor456;
public:
A():m_access123(*this),m_access456(*this){}
Accessor123& getAccessor123() { return m_access123; }
Accessor456& getAccessor456() { return m_access456; }

private:
void callPrivateA1(){}
void callPrivateA2(){}
void callPrivateA3(){}
void callPrivateA4(){}
void callPrivateA5(){}
void callPrivateA6(){}

private:
Accessor123 m_access123;
Accessor456 m_access456;
};

void A::Accessor123::callPrivateA1() { m_a.callPrivateA1(); }
void A::Accessor123::callPrivateA2() { m_a.callPrivateA2(); }
void A::Accessor123::callPrivateA3() { m_a.callPrivateA3(); }
void A::Accessor456::callPrivateA4() { m_a.callPrivateA4(); }
void A::Accessor456::callPrivateA5() { m_a.callPrivateA5(); }
void A::Accessor456::callPrivateA6() { m_a.callPrivateA6(); }

class B
{
void test()
{
A a;
// a.callPrivateA1(); // access illégale
a.getAccessor123().callPrivateA1();
//a.getAccessor456().callPrivateA2(); // access illégale
}
};

--
Vianney LANÇON
radix omnia malorum prematurae optimisatia est
-- Donald Knuth

Le Thu, 11 Dec 2003 13:37:40 +0100, dans fr.comp.lang.c++,
Jean-Marc Molina a dit :

friend permet normalement à la classe B d'accéder à l'ensemble des attributs
et méthodes de A, non ?

Le seule problème de cette solution c'est que B a accès à tout, alors qu'il
vaudrait qu'il n'ait accès qu'aux méthodes publics de A, non ?

La seule solution que je vois c'est de créer une DLL avec A et B dedans,
seule la classe B est exportée ce qui empêche l'application d'utiliser la
classe A. Une sorte d'interface. Je ne vois pas trop comment implémenter ce
système avec un motif d'interface (classe virtuelle pure...).

Il suffit de définir des classes qui gèrent les droits d'access à la
classe A.
A a pour friend ses "Accessor". Et ces accessor ne forward qu'une
partie des fonction de A.

De ce fait en utilisant friend pour un accessor, on garantis l'accès
qu'à un nombre limité de fonctions.

Il suffit ensuite de mettre toutes les fonctions de A en private.

Dans l'exemple suivant B n'a accès qu'à callPrivateA(1|2|3) mais
pas à callPrivateA(4|5|6).

class A
{
public:
class Accessor123
{
friend class B;
public:
explicit Accessor123(A& a):m_a(a){}
private:
void callPrivateA1();
void callPrivateA2();
void callPrivateA3();
private:
A& m_a;
};

class Accessor456
{
public:
explicit Accessor456(A& a):m_a(a){}
private:
void callPrivateA4();
void callPrivateA5();
void callPrivateA6();
private:
A& m_a;
};

friend class Accessor123;
friend class Accessor456;
public:
A():m_access123(*this),m_access456(*this){}
Accessor123& getAccessor123() { return m_access123; }
Accessor456& getAccessor456() { return m_access456; }

private:
void callPrivateA1(){}
void callPrivateA2(){}
void callPrivateA3(){}
void callPrivateA4(){}
void callPrivateA5(){}
void callPrivateA6(){}

private:
Accessor123 m_access123;
Accessor456 m_access456;
};

void A::Accessor123::callPrivateA1() { m_a.callPrivateA1(); }
void A::Accessor123::callPrivateA2() { m_a.callPrivateA2(); }
void A::Accessor123::callPrivateA3() { m_a.callPrivateA3(); }
void A::Accessor456::callPrivateA4() { m_a.callPrivateA4(); }
void A::Accessor456::callPrivateA5() { m_a.callPrivateA5(); }
void A::Accessor456::callPrivateA6() { m_a.callPrivateA6(); }

class B
{
void test()
{
A a;
// a.callPrivateA1(); // access illégale
a.getAccessor123().callPrivateA1();
//a.getAccessor456().callPrivateA2(); // access illégale
}
};

--
Vianney LANÇON
radix omnia malorum prematurae optimisatia est
-- Donald Knuth

Vous avez filtré cet utilisateur ! Consultez son message

Le Thu, 11 Dec 2003 13:37:40 +0100, dans fr.comp.lang.c++,
Jean-Marc Molina a dit :

friend permet normalement à la classe B d'accéder à l'ensemble des attributs
et méthodes de A, non ?

Le seule problème de cette solution c'est que B a accès à tout, alors qu'il
vaudrait qu'il n'ait accès qu'aux méthodes publics de A, non ?

La seule solution que je vois c'est de créer une DLL avec A et B dedans,
seule la classe B est exportée ce qui empêche l'application d'utiliser la
classe A. Une sorte d'interface. Je ne vois pas trop comment implémenter ce
système avec un motif d'interface (classe virtuelle pure...).

Il suffit de définir des classes qui gèrent les droits d'access à la
classe A.
A a pour friend ses "Accessor". Et ces accessor ne forward qu'une
partie des fonction de A.

De ce fait en utilisant friend pour un accessor, on garantis l'accès
qu'à un nombre limité de fonctions.

Il suffit ensuite de mettre toutes les fonctions de A en private.

Dans l'exemple suivant B n'a accès qu'à callPrivateA(1|2|3) mais
pas à callPrivateA(4|5|6).

class A
{
public:
class Accessor123
{
friend class B;
public:
explicit Accessor123(A& a):m_a(a){}
private:
void callPrivateA1();
void callPrivateA2();
void callPrivateA3();
private:
A& m_a;
};

class Accessor456
{
public:
explicit Accessor456(A& a):m_a(a){}
private:
void callPrivateA4();
void callPrivateA5();
void callPrivateA6();
private:
A& m_a;
};

friend class Accessor123;
friend class Accessor456;
public:
A():m_access123(*this),m_access456(*this){}
Accessor123& getAccessor123() { return m_access123; }
Accessor456& getAccessor456() { return m_access456; }

private:
void callPrivateA1(){}
void callPrivateA2(){}
void callPrivateA3(){}
void callPrivateA4(){}
void callPrivateA5(){}
void callPrivateA6(){}

private:
Accessor123 m_access123;
Accessor456 m_access456;
};

void A::Accessor123::callPrivateA1() { m_a.callPrivateA1(); }
void A::Accessor123::callPrivateA2() { m_a.callPrivateA2(); }
void A::Accessor123::callPrivateA3() { m_a.callPrivateA3(); }
void A::Accessor456::callPrivateA4() { m_a.callPrivateA4(); }
void A::Accessor456::callPrivateA5() { m_a.callPrivateA5(); }
void A::Accessor456::callPrivateA6() { m_a.callPrivateA6(); }

class B
{
void test()
{
A a;
// a.callPrivateA1(); // access illégale
a.getAccessor123().callPrivateA1();
//a.getAccessor456().callPrivateA2(); // access illégale
}
};

--
Vianney LANÇON
radix omnia malorum prematurae optimisatia est
-- Donald Knuth

Porté d'une fonction membre

6 réponses

Veuillez sélectionner un problème