En mode d'héritage privé tous les membres de la classe mère (attributs et méthodes) deviennent privés. Alors pourquoi la classe Pile qui hérite de la classe Tableau en mode privé peut accéder à l'attribut
nbrAccess
à travers la méthode vide()?
De plus on a dit que meme les méthodes publiques deviennent privées. Alors pourqoi le constructeur de la classe Pile appelle le constructeur de la classe Tableau.
Dans quels cas on utilise l'héritage en mode privé? Quelel est son utilité?
Mais le mode private change l'accessibilté des membres qu'ils soient publiques ou protégés en les rendant tous privés.
Je n'ai pas compris pourquoi la classe Pile utilise l'attribut nbrAccess dans ce cas?
class A
{
public:
int x;
protected:
int y;
private:
int z;
};
class B : public A
{
// x is public
// y is protected
// z is not accessible from B
};
class C : protected A
{
// x is protected
// y is protected
// z is not accessible from C
};
class D : private A // 'private' is default for classes
{
// x is private
// y is private
// z is not accessible from D
};
Comme l'indique la ligne 28, une variable protected devient privée par héritage privé, et reste donc accessible... (les membres privés sont toujours accessibles depuis l'intérieur de la classe). Si tu déclarais nbrAcces en privé dans Tableau, la ligne
nbrAcces++;
dans Pile::vide() déclencherait une erreur de compilation.
> C'est un héritage d'implémentation, donc un type d'héritage souvent très foireux.
Euh? Non. C'est un héritage d'importation de code qui bloque toute possibilité syntaxique de substitution. C'est parfait pour réutiliser sans mettre à mal le LSP. La même chose (changement complet d'interface & contrats) en mode héritage public serait infiniment pire.
Après, bien souvent la composition peut s'avérer préférable et suffire. Et parfois l'héritage privé est plus simple (genre liste & liste triée...)
PS: à moins que tu suives une formation avec prof qui te montre ça, recentre toi plutot sur les essentiels comme le RAII... Je range l'héritage privé dans les sujets avancés dans mes formations, et pas pour débutants.
les données privées d'une superclasse (par exemple un nom et prénom privés) sont hérités par une sous-classe. Mais cette dernière n'a pas le droit d'y accéder directement sauf à travers une fonction publique?
les données privées d'une superclasse (par exemple un nom et prénom privés) sont hérités par une sous-classe. Mais cette dernière n'a pas le droit d'y accéder directement sauf à travers une fonction publique?
Je ne suis pas un pro du C++, mais à mon sens, ta phrase me semble correcte.
Sur ce que j'ai pu comprendre, les membres privés d'une classe de base ne peuvent être directement accessibles que par les membres de la classe elle-même et ses amis. Cependant, ils peuvent être accessibles indirectement par les membres d'une classe dérivée via les fonctions publiques héritées.
Celui qui trouve sans chercher est celui qui a longtemps cherché sans trouver.(Bachelard) La connaissance s'acquiert par l'expérience, tout le reste n'est que de l'information.(Einstein)
les données privées d'une superclasse (par exemple un nom et prénom privés) sont hérités par une sous-classe. Mais cette dernière n'a pas le droit d'y accéder directement sauf à travers une fonction publique?
Bon, pour voir toi-même si tu as compris, c'est bien de reformuler, mais au lieu de nous poser la question (*), c'est mieux que tu essaies d'appliquer toi-même sur un exemple minimum.
En fait la question n'est pas d'accéder à des données privées, mais à des membres privés (fonctions et données). Ce que font les fonctions (privées ou publiques) de la classe de base, c'est autre chose.
Exemple, si on compile
class Base {
private:
void x() {}
public:
void y() {}
};
class Derivee : private Base
{
void foo() {
x();
y();
}
};
on se fait engueuler pour x, mais pas pour y.
g++ -c -o a.o a.cc
a.cc: Dans la fonction membre « void Derivee::foo() »:
a.cc:11:3: erreur: « void Base::x() » est privé dans ce contexte
11 | x();
| ^
a.cc:3:7: note: déclaré privé ici
3 | void x() {}
| ^
a.cc:11:5: erreur: « void Base::x() » est privé dans ce contexte
11 | x();
| ^
a.cc:3:7: note: déclaré privé ici
3 | void x() {}
| ^
Un Hasard ? Je Ne Crois Pas.
Et ce n'est pas la question que x/y qui sont définis dans Base manipulent ou non des données de Base.
(*) pour obtenir peut-être des réponses pas forcément exactes, qui tu interprèteras plus ou moins correctement. Ca ne restera que des mots. Bref, comprendre, c'est être capable de prévoir ce qui se passera. Pour ça il faut s'y coller : tester soi-même.
- Edité par michelbillaud 2 février 2023 à 11:56:21
Si un champ est privé dans une classe, c'est que c'est un détail d'implémentation et que les codes utilisateurs de cette classe n'ont pas à connaitre l’existence de ce champ pour pouvoir bénéficier des services offerts par la classe.
Je recherche un CDI/CDD/mission freelance comme Architecte Logiciel/ Expert Technique sur technologies Microsoft.
La gestion des accès est plutôt basique. Une fonction membre d'une classe Dérivée a les possibilités d'accès suivante sur sa Base: - les membres public de la Base sont totalement accessibles, donc c'est comme pour tout le monde. - les membres private de la Base ne sont pas accessibles, donc c'est comme pour tout le monde. - les membres protected d'un objet de type Base ne sont pas accessibles, donc c'est comme pour tout le monde. - seule exception : dans un objet de de type Dérivée, les membres protected de la Base peuvent être accédés (contrairement au reste du monde). On peut remarquer qu'à aucun moment ça ne dépend du type d'héritage!
Le type d'héritage public ou privaten'a d'influence que sur ce que voient les "autres" de la classe Dérivée. - héritage public. On peut alors dire "Dérivée" est une sorte de "Base" et faire des conversions de pointeurs ou de références en relation avec ça. Les membres de Basepublic sont donc accessibles. - héritage private. Cet héritage n'est pas visible des "autres", en particulier: --- on ne peut pas convertir une référence à Dérivée en référence à Base (sauf bidouille du genre cast à la C) --- si on tente d'accéder à un des membres de Base pour un objet de type Dérivée, tout ce passe comme si le membre n'existait pas. Tous les membres quels qu'ils soient sont considérés private.
Donc l'héritage private n'est pas un héritage! Le plus souvent il est beaucoup plus propre et beaucoup plus sage de remplacer ce type d'héritage par une relation d'inclusion.
Donc l'héritage private n'est pas un héritage! Le plus souvent il est beaucoup plus propre et beaucoup plus sage de remplacer ce type d'héritage par une relation d'inclusion.
#include <iostream>
using namespace std;
class A{
public: int x;
protected: int y;
private: int z;// accessible uniquement de A
public:
A(int a, int b, int c): x(a),y(b),z(c){}
void afficheA(){
cout << x << " " << y <<" " << z <<" " ;
}
void afficheZ(){
cout <<" " << z << endl;
}
};
class D : private A
{
protected: int d;
//x is private
//y is private
//z is inaccessible from D
public:
D(int j, int k, int l, int m): A(j,k,l), d(m){}
void afficheD(){
cout << x <<" "<<y <<" "<<d;
afficheZ();
}
};
class E: private D
{
// d: private
// x: innaccessible from E
//y: innaccessible from E
// z: innaccessible from E
public:
E(int i, int j, int k, int l): D(i,j,k,l){}
void afficheE()
{
afficheD();
}
};
int main()
{
A p(1,2,3);
p.afficheA();
cout << endl;
D q(5,6,7,8);
q.afficheD();
E e(9,10,11,12) ;
e.afficheE();
return 0;
}
Pour la classe E dont les attributs x, y et z sont inaccessibles, est ce qu'on peut dire que la classe E admet un seul attribut (d) ou elle en possède 4?
Ne te prends pas trop la tête avec les termes compliqués issus de l'UML, cela n'en vaut pas la peine...
Ce qu'il faut savoir, en commençant par le début, c'est:
En terme de niveau d'accès le "monde" se divise en trois grandes "catégories":
la classe elle-même, ou, plus précisément, les fonctions qui font partie de la classe
les éventuelles classes dérivées, ou, plus précisément, les fonctions qui font partie des classes dérivées et
"le reste du monde": n'importe quelle fonction susceptible de manipuler une instance de la classe
Pour faire une comparaison à peu près juste, nous pourrions dire qu'il y a moi, mes enfants et "les autres":
Je suis composé d'éléments que mêmes mes enfants ne partagent pas: les os et les organes. C'est ce qui se trouve dans l'accessibilité "private"
Mes enfant partagent (une partie) de mon ADN, qui me vient de mes parents, et qu'ils ont eux même hérité de leurs parents (et ainsi de suite). C'est ce qui se trouve dans l'accessibilité "protected".
Le reste du monde a accès à "un certain nombre" d'éléments de ma part : ma taille, la couleur de mes yeux ou de mes cheveux, le ton de ma voix, mon aspect général, j'en passe et de meilleures. C'est ce qui se trouve dans l'accessibilité "public".
Quand il est question d'héritage, les différents niveaux d'accessibilités au pire, l'accessibilité des éléments de la classe de base est réduite au niveau de la classe dérivée, mais elle ne sera jamais augmentée.
Ainsi, si tu envisages un héritage public, les fonctions publiques de la classe de base seront publiques au niveau de la classe dérivée (les fonctions de la classe dérivée et "le reste du monde" peuvent y accéder); les élément protégés de la classe de base seront protégés au niveau de la classe dérivée (les fonctions de la classe dérivée peuvent y accéder), et ce qui est privé au niveau de la classe de base n'est ... accessible qu'aux fonctions de la classe de base (mais pas à celles de la classe dérivée).
Par contre, si tu envisages un héritage "restreint" (protégé ou privé), l'accessibilité des éléments de la classe de base qui sont accessibles à la classe dérivée ou au "reste du monde" est réduite -- pour la classe dérivée -- au niveau d'accessibilité utilisé pour l'héritage.
Ainsi, si tu envisages un héritage protégé, les élément publiques et protégés de la classe de base le niveau d'accessibilité de ces éléments sera perçu au niveau de la classe dérivée comme étant protégé, et, si tu envisage un héritage privé, l'ensemble de la classe de base sera perçu comme étant privé au niveau de la classe dérivée.
Et, bien sur, dans tous les cas, les éléments privés de la classe de base restent carréement inaccessibles, tant pour la classe dérivée que pour le reste du monde.
LinaAbid a écrit:
Pour la classe E dont les attributs x, y et z sont inaccessibles, est ce qu'on peut dire que la classe E admet un seul attribut (d) ou elle en possède 4?
On pourrait le dire, mais, en fait, cela n'a simplement pas de sens...
La principale raison est qu'une classe devrait -- dans l'idéal -- être perçue comme "un fournisseur de services" et qu'un attribut (une donnée membre) n'a de l'intérêt que parce qu'elle est nécessaire pour fournir un des services attendus de la part de la classe. Or, les services en questions sont fournis ... par des fonctions, dont on pourra définir le comportement.
Si bien que si une donnée membre n'est utilisée par aucune des fonction au niveau (ou à l'extérieur) de la classe, elle ne sert tout simplement ... à rien. Je m'explique:
Je pourrais tout à fait envisager de créer une classe Date qui resemble à ceci:
class Date{
public:
/* le constructeur */
Date(int year, int month, int day);
/* je m'attends à profiter des services suivants
* depuis l'extérieur
*/
int year(); // répond à la question quelle est l'année
int month();// répond à la question quelle est le mois
int day(); // répond à la question quelle est le jour
bool isValid(); //répond à la question "la date est-elle
// valide (le 31 fevrier n'étant pas
// une date valide);
private:
/* quelques services internes */
bool isBissextile(int year); // vérifie si une année
// est bissextile
/* indique le nombre maximal de jours qui composent un
* mois donné en fonction de l'année envisagée
*/
int maxDayPerMonth(int year, int month);
int year_;
int month_;
int day_;
int captainAge_;
};
Si ce n'est que, dans cette classe, l'âge du capitaine ne sera jamais utilisé par aucune des fonctions que je prévois de créer. Il ne va donc servir ... à rien, si ce n'est à rendre les choses inutilement plus complexes, et à faire se demander aux développeur à quoi il sert.
Or, le meilleur conseil que l'on puisse donner à un développeur est sans doute ce que l'on énonce sous la forme de KISS en "Xtrem-programming" (Keep It Simple, Stupid ou, en francais, garde cela simple, idiot), ou, comme le disait einstein : "Rendez les choses aussi complexes que nécessaires, mais guère plus".
Car il faut te dire que la probabilité d'avoir un problème, un bug dans le code augmente de manière quasiment exponentielle par rapport au nombre d'instructions et au nombre de développeurs qui interviennent le code.
Ainsi, si, avec dix instructions écrites par un seul développeur, la probabilité d'avoir un bug est de 100. Avec 11 instructions, la probabilité d'avoir un bug monte directement à ... 121 pour un seul développeur. Et à 484 si ces 11 instructions venaient à être écrites par deux développeurs différents.
(bon, ces chiffres sont sans doute surévalués, cependant, ils illustrent bien la proportion dans laquelle le risque de bug augmente )
Ce qui se conçoit bien s'énonce clairement. Et les mots pour le dire viennent aisément.Mon nouveau livre : Coder efficacement - Bonnes pratiques et erreurs à éviter (en C++)Avant de faire ce que tu ne pourras défaire, penses à tout ce que tu ne pourras plus faire une fois que tu l'auras fait
Dans l'exemple que j'ai donné, est ce que j'ai le droit de construire un objet E à partir de 4 valeurs malgré que x, y et z sont inaccessibles par E ?
class E: private D
{
// d: private
// x: innaccessible from E
//y: innaccessible from E
// z: innaccessible from E
public:
E(int i, int j, int k, int l): D(i,j,k,l){}
void afficheE()
{
afficheD();
}
};
int main()
{
E e(9,10,11,12) ;
e.afficheE();
return 0;
}
Où est le problème ? Il ne sont pas accessibles par E, mais par le constructeur de D, oui... Les constructeurs vont s'appeler les uns les autres dans ton exemple, chaque constructeur appelle celui de son parent. On peut constater que ça compile en plus. Le compilateur râlerait si tu violais les règles d'encapsulation. Il est fait pour ça
Par le constructeur de D, et toutes les fonctions membres (méthodes) de D.
Parce que si on définit des données membres privées, c'est parce qu'on les utilise dans les méthodes de la classe (ou amies, selon les chinoiseries introduites par C++ pour contourner l'accessibilité normale, en l'absence de packages etc).
> Dans l'exemple que j'ai donné, est ce que j'ai le droit
Rediffusion :
> Bon, pour voir toi-même si tu as compris, [...] au lieu de nous poser la question (*), c'est mieux que tu essaies d'appliquer toi-même sur un exemple minimum.
Y a une démarche scientifique derrière
on pense à des trucs
on essaie de formuler une hypothèse
on monte une petite expérience pour confirmer/invalider l'hypothèse
on en tire des conclusions, on améliore les hypothèses et on recommence.
- Edité par michelbillaud 12 février 2023 à 12:40:23
...En terme de niveau d'accès le "monde" se divise en trois grandes "catégories":
la classe elle-même, ou, plus précisément, les fonctions qui font partie de la classe
les éventuelles classes dérivées, ou, plus précisément, les fonctions qui font partie des classes dérivées et
"le reste du monde": n'importe quelle fonction susceptible de manipuler une instance de la classe
Pour faire une comparaison à peu près juste, nous pourrions dire qu'il y a moi, mes enfants et "les autres":
Je suis composé d'éléments que mêmes mes enfants ne partagent pas: les os et les organes. C'est ce qui se trouve dans l'accessibilité "private"
Mes enfant partagent (une partie) de mon ADN, qui me vient de mes parents, et qu'ils ont eux même hérité de leurs parents (et ainsi de suite). C'est ce qui se trouve dans l'accessibilité "protected".
Le reste du monde a accès à "un certain nombre" d'éléments de ma part : ma taille, la couleur de mes yeux ou de mes cheveux, le ton de ma voix, mon aspect général, j'en passe et de meilleures. C'est ce qui se trouve dans l'accessibilité "public".
Quand il est question d'héritage, les différents niveaux d'accessibilités au pire, l'accessibilité des éléments de la classe de base est réduite au niveau de la classe dérivée, mais elle ne sera jamais augmentée.
Ainsi, si tu envisages un héritage public, les fonctions publiques de la classe de base seront publiques au niveau de la classe dérivée (les fonctions de la classe dérivée et "le reste du monde" peuvent y accéder); les élément protégés de la classe de base seront protégés au niveau de la classe dérivée (les fonctions de la classe dérivée peuvent y accéder), et ce qui est privé au niveau de la classe de base n'est ... accessible qu'aux fonctions de la classe de base (mais pas à celles de la classe dérivée).
Par contre, si tu envisages un héritage "restreint" (protégé ou privé), l'accessibilité des éléments de la classe de base qui sont accessibles à la classe dérivée ou au "reste du monde" est réduite -- pour la classe dérivée -- au niveau d'accessibilité utilisé pour l'héritage.
Ainsi, si tu envisages un héritage protégé, les élément publiques et protégés de la classe de base le niveau d'accessibilité de ces éléments sera perçu au niveau de la classe dérivée comme étant protégé, et, si tu envisage un héritage privé, l'ensemble de la classe de base sera perçu comme étant privé au niveau de la classe dérivée.
Et, bien sur, dans tous les cas, les éléments privés de la classe de base restent carréement inaccessibles, tant pour la classe dérivée que pour le reste du monde.
...
Merci pour la comparaison, mercipour l'explication ! J'ai enfin compris! (D'accord, ne vous moquez pas ! Vieux motard que jamais!)
× Après avoir cliqué sur "Répondre" vous serez invité à vous connecter pour que votre message soit publié.
× Attention, ce sujet est très ancien. Le déterrer n'est pas forcément approprié. Nous te conseillons de créer un nouveau sujet pour poser ta question.
Discord NaN. Mon site.
Celui qui trouve sans chercher est celui qui a longtemps cherché sans trouver.(Bachelard)
La connaissance s'acquiert par l'expérience, tout le reste n'est que de l'information.(Einstein)
En recherche d'emploi.
Discord NaN. Mon site.