Implémentation privée et héritage

**robinsondesbois** · 25/01/2016, 15h46

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** · 25/01/2016, 15h53

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** · 25/01/2016, 15h58

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** · 25/01/2016, 16h12

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** · 25/01/2016, 22h02

Envoyé par 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.

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! :

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"
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** · 26/01/2016, 09h17

Très bonne loi

Où puis-je trouver d'autre axiome de la programmation ?

**ternel** · 26/01/2016, 11h30

En cherchant C++ SOLID.

Par exemple, sur wikipedia (anglais)

Il y a un autre schéma de conception, le RAII.
C'est assez discret, et très présent.
Le principe, c'est d'utiliser le fait qu'en C++, le destructeur d'une variable locale est appelé une et une seule fois (à moins de faire de le faire exprès, et encore, c'est toujours très sale), pour s'assurer qu'une certaine action est faite.

Par exemple, std::vector n'est en fait qu'un tableau dynamique.
En C, on utiliserait un pointeur, un malloc, des reallocs et un free. Mais il faudrait que l'utilisateur du tableau surveille partout dans son code s'il faut le détruire ou non
En C++, std::vector est conçu en RAII pour s'assurer que le tableau alloué en interne est correctement supprimé: une et une seule fois.

Tu trouves exactement cette problématique (et la même gestion) dans string, list, map, etc.

Autre exemple, les fichiers. Avec fstream, il n'est pas nécessaire d'appeler close(), vu que le destructeur le gère correctement. Surtout si le fstream est déclaré au dernier moment.

Le cas le plus emblématique est cependant le std::unique_ptr<...>, mais cela a largement été discuté sur ce forum.