Discussion :

[robinsondesbois]

Bonjour,

Je souhaiterais pouvoir accéder aux membres de ma classe mère dans ma classe fille en utilisant le pattern implémentation privé.

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
class A {
private:
	class Impl_;
	Impl_ impl_;
};
 
class A::Impl_ {
public:
	Impl_() {}
 
	~Impl_() {}
 
public:
	int number_;
};
 
 
class B : public A {
	B() {
		std::cout<<impl_->number_;
	}
private:
	class Impl_;
	Impl_ impl_;
};
 
class B::Impl_ {
public:
	Impl_() {}
 
	~Impl_() {}
};

Merci d'avance
Robin

[koala01]

Salut,

Non, tu ne veux pas accéder aux membres privés de ta classe mère!!!

Ce que tu veux, et ce que tu peux, c'est:
accéder au fonctions membre publiques de la classe mère depuis la classe dérivée
accéder aux fonctions membres protégées de la classe mère depuis la classe dérivée.

Tout autre souhait t'emmènera vers un noeud de problème que même Alexandre le grand n'arrivera pas à trancher

Par contre, tu souffres visiblement d'un problème bien connu : tu réfléchis à tes classes en fonction des données qu'elles manipulent, alors que tu devrais y penser en termes des services qu'elles proposent / dont l'utilisateur de la classe est en droit de s'attendre à pouvoir profiter.

Une fois que tu auras passé ce cap, tu te rendra compte qu'il y a des services "destinés à tous", qui peuvent apparaitre dans l'accessibilité publique, des services "à usage limité aux classes dérivées" qui doivent donc apparaitre dans l'accessibilité protégée et des services "à usage interne uniquement" qui devront apparaitre... dans l'accessibilité privée

[ternel]

si ce fameux number est une propriété observable, la classe de base doit fournir une méthode pour obtenir sa valeur.
Qu'il matérialisé par une variable ou calculé.

[robinsondesbois]

Ok.
C'est donc une erreur de ma part de vouloir faire ceci ^^
Merci pour vos réponses. Je vais donc faire un accesseur protected.

[koala01]

Ok.
C'est donc une erreur de ma part de vouloir faire ceci ^^
Merci pour vos réponses. Je vais donc faire un accesseur protected.

Fournir un comportement, un service est une bonne chose. Le fait de le placer dans l'accessibilité protégée également.

Mais, pourquoi en faire un accesseur

Je ne sais pas quelles sont les données qui t'intéressent, mais l'accesseur n'est pas forcément le meilleur moyen d'arriver à quelque chose de cohérent! :

1. Si tu veux un "GO/NO GO", crées un comportement qui évalue la capacité à effectuer ce qui t'intéresse en fonction des données externes dont la classe enfant dispose (par nature ou par argument) et qui renvoie true si on est "dans les limites admises" et false si on est "hors limites"
2. Si tu veux appliquer une modification, crées un comportement qui vérifie si on est dans les limites acceptables pour que comportement survienne et qui modifie les données membre en conséquence (enfin, si on est dans les limites, s'entend )

N'oublie pas la fameuse loi de Déméter :

si un objet de type A manipule en interne un objet de type B, l'utilisateur du type A ne doit pas avoir à connaitre le type B pour manipuler son type A

On a beau être dans un cas particulier du fait de l'héritage, la loi de Déméter reste de stricte application : si on décide qu'une donnée appartient à la classe de base, c'est uniquement pour lui permettre d'"exposer" un service particulier que l'on est en droit d'attendre de sa part (quelle que soit l'accessibilité dans laquelle se trouve le service concerné), si bien que la seule chose dont les classes dérivées (et autres classes sans aucun lien avec la classe de base) puise n'avoir qu'une seule préoccupation : ai-je accès à ce service A charge pour la classe de base que le service rendu soit cohérent avec ce que l'on attend de sa part .

Or la création d'un accesseur -- quelle que soit son accessibilité -- n'a réellement du sens que s'il correspond bel et bien à la possibilité d'obtenir une réponse à l'interrogation que l'on se pose sur un état particulier à un instant T particulier de la classe en question.

De mon expérience, on a très rarement besoin de telles informations : on a bien souvent des questions plus "complexes" à poser (comme "puis-je faire ceci" ou "dois-je faire cela") qui correspondent bien d'avantage aux services que l'on est effectivement en droit d'attendre de la classe . Surtout si l'accessibilité de tels services est limitée

[robinsondesbois]

Très bonne loi
Où puis-je trouver d'autre axiome de la programmation ?