Discussion :

[Ekinoks]

Salut !

J'ai un problème d'encapsulation, je n'arrive pas à trouver de moyen pour que chaque classe n'est accès qu'as ce qu'il a besoin.

Voici le code :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
 
// Charger de s'occuper de "type value_" (création / suppression / stockage)
class Value
{
	public :
		Value(type value) : value_(value) {}
 
	private :
		type value_;
};
 
// classe mere qui sera hérité par beaucoup de classe fils
class Mere
{
	public :
		Mere(type t) : v_(t)
		{
		}
		//...
 
	private :
		Value v_;
		//...
};
 
// Cette classe et ses descendants doivent être les seul qui on le droit d'accéder à "Value::value_"
class SeulClassQuiUtiliseValue
{
	public :
		void getValue(A &a)
		{
			// besoin d'utiliser A.v.value_
		}
};

Quelque solution :
1) Créer des accesseurs de "v_" dans "Mere" et de "value_" dans "Value".
Problème : Toute les classe qui hérite de la classe "Mere" auront un moyen d'accéder également a "value_" en utilisant les accésseurs.

2) Mettre SeulClassQuiUtiliseValue::getValue(A &a) comme amie de "Mere" et de "Value"
Problème : Cette méthode "getValue" auras un accès complet au membre privé de "Mere" alors que seulement "v_" nous intéresse.

3) Créer un accésseur de "V_" dans classe "Mere" et mettre SeulClassQuiUtiliseValue::getValue(A &a) comme amie de "Value".
Problème : Toute les classe qui hérite de la classe "Mere" auront accès a "v_".
Bien qu'ils ne puissent rien en faire directement car pas accès a "value_",
on pourrais être tenté d'utiliser ce "v_" comme argument pour une méthode de "SeulClassQuiUtiliseValue" (ou une classe dérivé).
Ainsi, la classe Value jouerait un rôle dans les classe dérivé de la classe "Mere" alors quel ne devrais pas.


Les trois solutions au quel j'ai pensé présente toutes des inconvenants...
Existerait il d'autre solutions pour résoudre ce problème ?
Et si aucune autre solution existe, quel serais la meilleur ?

Merci pour votre aide.

[koala01]

Salut,

En fait, il y a un mix de tout à faire:

1. Rendre la classe Value non copiable et non assignable ( == déclarer sans les définir le constructeur par copie et l'opérateur d'affectation dans l'accessibilité private)
2. Déclarer le membre de type value uniquement dans la classe qui en a besoin (dans l'accessibilité priavate)
3. Déclarer la classe qui a besoin de Value::value_ (ou une de ses méthodes private) amie de la classe Value

Cela prendrait la forme de

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
class Value; // déclaration anticipée de la classe, pour qu'elle soit connue
             // lorsque le compilateur la rencontre dans ClassQuiUitiliseValue
class Mere
{
    /*aucune référence à la classe Value ici */
    public:
        Mere(){}
        virtual ~Mere(){}
        /* méthodes publiques  */
    private:
        /* membres et méthodes privées */
};
class ClassQuiUitiliseValue : public Mere
{
    public:
        ClasseQuiUtiliseValue( type v): val_(v){}
        virtual ~ClasseQuiUtiliseValue(){}
        /* les méthodes qui vont bien et qui peuvent être publiques */
    private:
        /* Seule ClasseQuiUtiliseValue pourra accéder à cette méthode
         * mais son implémentation doit être déportée après la définition
         * réelle de la classe Value 
         */
        /* inline */ le_type_qui_va_bien function();
        Value val_;
};
class Value
{
    public : 
        /* il pourrait être private... mais donnons nous l'occasion de
         * quand meme la construire
         */
        Value(type value_):value_(value_){}
        /* d'office public, sinon nous aurons un problème */
        ~Value(){}
    private:
        type value_;
        /*La copie est interdite  */
        Value(const Value&);
        /* l'affectation itou */
        Value operaor= (const Value&);
        friend le_type_qui_va_bien ClasseQuiUtiliseValue::function();
};
/*inline */ le_type_qui_va_bien ClasseQuiUtiliseValue::function()
{
    /* ce qu'il faut faire, en pouvant très bien envisager un code proche de*/
    type temp = val_::value_;
}

[koala01]

Pour te permettre d'en comprendre un peu plus sur l'amitié...

Si tu déclare une classe amie, il faut savoir que l'amitié n'est ni transitive, ni réciproque, ni héritée (et c'est ce dernier terme qui nous intéresse).

Cela signifie que seules les méthodes qui peuvent être utilisées en faisant passer une instance d'une autre classe pour une instance de la classe déclarée amie pourront envisager d'accéder aux membres et méthodes non publiques.

En outre, une classe dérivée n'a acces qu'aux membres et méthodes publiques ou protégés (mais en aucun privés) de la classe dont elle dérive.

Ainsi, si tu as un code proche de

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
 
class Mere
{
    public:
        /*...*/
        void foo();
        type1 publicMember;
    protected:
        void bar();
        type2 protectedMember;
    private:
        void privateFoo();
        type3 privateMember;
};
class Derivee : public Mere
{
    /*...*/
};

la classe Derivee ne pourra accéder qu'à foo, bar, publicMember et protectedMember...

Si même, tu en venais à rendre (par exemple) foo virtuelle et à la spécialiser (dans une optique de polymorphisme) dans dérivée, tu devrais passer par Mere::foo pour avoir réellement acces aux membres non public de la classe qui déclare mère amie.

Ainsi, un code proche de

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
class Value
{
    public:
        friend class Mere;
        Value(int i):i(i){}
        ~Value(){}
    protected:
    private:
        int i;
};
 
class Mere
{
    public:
	Mere(const Value& v):v(v){}
        virtual ~Mere(){}
        virtual void foo(){cout<<"dans mere "<< v.i<<endl;}
    protected:
        virtual void bar(){}
        Value v;
    private:
 
};
class Fille : public Mere
{
    public:
        Fille(const Value& v):Mere(v){}
        virtual ~Fille(){}
        virtual void foo()
        {
            cout<<"dans fille "<< v.i<<endl; //refusé
            /* par contre ce qui suit serait accepté
             * cout<<"Fille appelle Mere::foo ";
             * Mere::foo();
             */                          
        }
    protected:
        virtual void bar(){}
    private:
 
};

refusera de compiler au prétexte que v::i est privé dans le contexte de Fille::foo (bien quelle puisse accéder à v, étant donné que le membre est protégé)...

Si, en plus, tu venais à placer v (ou la fonction qui doit y accéder) dans l'accessibilité privée de Mere, Fille ne pourrait même pas accéder ni à v ni à la fonction qui tente d'y accéder (et cette fonction ne pourrait d'ailleurs pas être spécialisée dans la classe dérivée)

[Ekinoks]

Un grand merci koala pour ta réponse =)

1. Rendre la classe Value non copiable et non assignable ( == déclarer sans les définir le constructeur par copie et l'opérateur d'affectation dans l'accessibilité private)
2. Déclarer le membre de type value uniquement dans la classe qui en a besoin (dans l'accessibilité priavate)
3. Déclarer la classe qui a besoin de Value::value_ (ou une de ses méthodes private) amie de la classe Value

2> Ha oui, effectivement, en modifiant un peu ma conception pour faire en sorte que ce soit "ClassQuiUitiliseValue" qui stock également "Value" ça arrange pas mal de chose ! =)
3 > Mais, du coup, si on arrive à mettre en place le second point, ça ne sert plus à rien de protéger d'avantage la classe "Value" non ? vue que SEUL "ClassQuiUitiliseValue", stock et utilise "Value".
1> Pareil que pour le points 3, si on arrive à mettre en place le point 2, je n'arrive pas à voir à quoi sert cette sécurité supplémentaire ?

Une dernière question, si jamais, la conception fait qu'on ne puisse pas utiliser le point (2), comment faire ? (si il existe des cas ou on ne puisse pas appliquer le point (2) ?)


Merci pour votre aide.

[koala01]

Il est vrai que l'utilité du point 1 est discutable, mais c'est surtout pour éviter la tentation d'écrire une méthode dans une autre classe qui tenterait de créer une instance de Value (c'est d'ailleurs la raison pour laquelle je verrais bien placer le constructeur en accessibilité privée, ainsi, seule les classes déclarées amies pourront créer une instance de Value )

Le point 3 est obligatoire, si tu veux que la classe qui utilise la classe Value puisse... accéder à la valeur du membre (car, si tu crées un accesseur pour ce membre, tu permet à n'importe quelle classe d'y accéder )

[Ekinoks]

Ha ok, ca y est je crois que j'ai compris, en faite tu te place au niveau de la classe "Value" et pas au niveau du projet dans sa globalité.

Au lieu de dire : "C'est à la classes qui contient 'Value' que revient la responsabilité de bien utiliser m'utiliser".
Tu dit : "C'est à la classes 'Value' de dire qui à le droit de m'utiliser (qui a la responsabilité de bien m'utiliser)".


C'est bien ça ?

[koala01]

C'est effectivement quelque chose dans le genre...

Mais, à vrai dire, je n'ai pas énormément le choix, étant donné que tu souhaite ne pas placer d'accesseur sur les membre de Value... il faut donc bien décider à un moment de qui aura la responsabilité d'autoriser (ou non) l'accès aux données