Discussion :

[pierrot10]

Bonjou,

J'ai maintenant un doute entre une variable protected et private

J'essaye d'utiliser une valriable _cell, mais je recois un message d'erreur m'indiquant qu'elle "protected".

Je pense que c'est parce que j'essaye de l'utiliser en dehor du scope.

Je pense que je dois la déplacé et la mettre comme publique.

Mais alors qu'elle sont les risques si je la mets en public?
je pense, qu'il y a en a pas beaucoup.


Maintenant, si je la passe en private, que se passera -t-il (en dehor de ma problématique)?

[Bousk]

Bonsoir,

Oui, enfin, y'a quand même une entrée de la FAQ qui reprend quasi mot pour mot ton titre donc bon... ?

[koala01]

Salut,

Il ne faut jamais mettre le membre d'une classe dans une accessibilité plus permissive "bêtement" parce que le compilateur se plaint de ne pas pouvoir y accéder.

De manière générale, si le compilateur se plaint de ne pas pouvoir accéder à une variable parce qu'elle est "protected in this context" (ou "private in this context"), tu dois partir du principe que c'est surtout parce qu'il n'est pas prévu que tu y accède de cette manière.

Il t'appartient donc de vérifier au niveau de l'interface (comprend: les fonctions publiques) quelle est la fonction qui sera la plus adaptée pour pouvoir manipuler la donnée recherchée (que ce soit en lecture ou en modification).

Mais il faut, surtout, que tu prennes conscience que, si on passe sous silence le principe de base du paradigme OO (qui est la substituabilité, telle que définie par Barbara Liskov dans le principe de substitution qui porte son nom), ce paradigme nécessite une approche totalement différente des langages qui n'utilisent que le paradigme impératif (comme C, par exemple).

En effet, si tu vas essentiellement t'inquiéter des données qui composent tes structures en C, tu vas devoir réfléchir à la notion de "services rendus" par tes classes si tu veux avoir une conception correcte dans un langage orienté objets.

Ainsi, si tu veux créer une structure "personne" en C, tu vas commencer par réfléchir aux différentes données qui te permettront de définir les différentes personnes, alors que si tu veux créer une classe "personne" en C++, tu devrais commencer par réfléchir à "quels sont les services que j'en attend" (ou, dans ce cas particulier "quelles sont les questions auxquelles je veux que la classe puisse répondre).

Tu commenceras donc par te dire que, bah, tu veux qu'elle puisse répondre aux questions:

• Quel est ton nom
• Quel est ton prénom
• Quel est ton age
• Quelle est ton adresse
• j'en oublie peut etre

En tant qu'utilisateur de ta classe, tu te fous pas mal de la manière dont celle ci va être en mesure de fournir la réponse: ce qui t'importe c'est que la réponse soit correcte. La manière dont ces données sont représentées dans la classe n'intéresse donc que... celui qui la développe.

Oui, je sais, ca fait sans doute bizarre étant donné que c'est aussi toi , mais ce qu'il est important de comprendre, c'est que ces données ne sont plus que "des détails d'implémentation" qui permettront à ta classe de fournir les services que tu attends de sa part.

La classe est une sorte de "boite noire" dont on ne connais que les fonctions publiques.

S'il fallait faire un parallèle avec C, cela correspondrait à la structure FILE, dont personne ne sait exactement de quoi elle est composée, mais dont on sait que les fonction fscanf, fprintf, fopen et autre fclose feront exactement ce que l'on attend d'elles

En revenant à ta variable _cell, si le développeur a décidé de la mettre en accessibilité protégée, c'est qu'il a décidé de placer un gros panneau "touche pas à ca p'tit con" (référence à l'un des septième compagnie ) destiné aux utilisateur de la classe

Maintenant, pour que tu comprennes ce que sont ces accessibilités "public" "protected" et "private".

L'accessibilité "private" est l'accessibilité la plus restrictive que tu puisse trouver: il n'y a que les fonctions membres de la classe ou les fonctions qui profitent de l'amitié qui peuvent y accéder.

L'accessibilité "protected" est un tout petit peu moins restrictive que l'accessibilité privée car elle permet non seulement au fonctions membre de la classe d'y accéder, mais aussi à toutes les fonctions membres des classes dérivées de manière directe ou indirecte (comprends: qui héritent) de la classe d'accéder à ce qui se trouve dans cette accessibilité.

Enfin l'accessibilité "public" est particulièrement permissive: strictement tout et n'importe quoi peut accéder à quelque chose qui est déclaré public

Un petit exemple pour te permettre de comprendre:

Mettons les classes Base et Derivee qui ressembleraient à ceci

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
class Base{
    public:
        void uneFonctionPublique();
    protected:
        void uneFonctionProtegee();
    private:
        int unMembrePrive;
};
class Derivee : public Base{
    public:
        void uneAutreFonctionPublique();
};

"N'importe qui" pourrait accéder tout à fait librement à la fonction uneFonctionPublique au départ d'un objet de type Base ou d'un objet de type Derivee et à la fonction uneFonctionProtegee au départ d'un objet de type Derivee:

Code :

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

1
2
3
4
5
6
7
8
int main(){
    Base maBase;
    maBase.uneFonctionPublique(); // OK
    Derivee maDerivee;
    maDerivee.uneFonctionPublique(); // OK (grace à l'héritage)
    maDerivee.uneAutreFonctionPublique(); // OK
    return 0;
}

uneFonctionPublique et uneAutreFonctionPublique peuvent toutes les deux accéder à uneFonctionProtegee parce que Derivee hérite de Base, mais tu ne pourras pas accéder à uneFonctionProtegee depuis "n'importe où":

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
void Base::uneFonctionPublique(){
    uneFonctionProtegee(); // OK : on est dans une fonction de la classe Base
}
void Derivee::uneAutreFonctionPublique(){
    uneFonctionProtegee(); // OK : Derivee hérite de Base et peut donc accéder 
                           // aux membres protected de cette dernière
}
int main(){
     Base maBase;
     maBase.uneFonctionProtegee(); // KO : fonction inaccessible depuis "n'importe ou"
     Derivee maDerivee;
     maDerivee.uneFonctionProtegee(); // KO : fonction inaccessible depuis "n'importe ou"
    return 0;
}

Enfin, seules les fonctions membres de Base (mais en aucun cas celles de Derivee) pourront accéder à unMembrePrive... Et il sera fatalement interdit d'y accéder depuis "n'importe où":

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
void Base::uneFonctionPublique(){
    unMembrePrive += 3; // OK : on est dans une fonction de la classe Base
}
void Base::uneFonctionProtegee(){
    unMembrePrive *= 5; // OK : on est dans une fonction de la classe Base
}
void Derivee::uneAutreFonctionPublique(){
    unMembrePrive /= 2  // KO: Derivee ne peut pas accéder aux membres privés de Base
}
int main(){
     Base maBase;
     int i = maBase.unMembrePrive // KO : on ne peut pas accéder à ce membre depuis "n'importe où"
     Derivee maDerivee;
     maDerivee.unMembrePrive+=10; // KO et encore moins de la sorte
    return 0;
}