Discussion :

[tabkelm]

bonjour,

J'ai une classe qui dérive d'une autre classe comme ceci:

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
 
#include <iostream>
#include <stdio.h>
 
class program{
 
  int non_public;
 
  public:
    int a;
    int b;
  int somme(int c,int d)
  {  int e;
     e=c+d;
     return e;
  }  
 
};
 
class toto : program
{
void Start()
  {
  program objet;
  }
 
};

Après avoir crée dans Start un objet de la classe program,y a-t-il un moyen d'accéder à la variable non_publique de classe program?
Si oui,comment?


merci de votre aide

[tatayo]

Bonjour,
Si le membre non_public est privé, il n'est pas accessible en dehors de la classe.
Pour qu'il soit accessible depuis les classes dérivées, il faut le passer en protected.

Mais pour moi il faut le laisser en private, et ajouter des accesseurs (l'équivalent d'une propriété en C#), protected si besoin, à la classe de base.

Tatayo.

[dalfab]

Bonjour,

Si le membre est privé, c'est que l'on a une bonne raison de désirer que ce membre ne soit pas accédé.
Alors, est-ce que c'est possible? Oui, à partir d'un point où c'est autorisé. Non, à partir d'un point interdit.

La question devient alors as-tu une bonne raison de vouloir le faire d'un point non autorisé? Il existe plusieurs solutions à ton problème cela dépend surtout de tes actions possibles sur le type qui à protégé le membre.

Décris mieux le pourquoi tu désires faire ceci, on pourra certainement t'indiquer comment résoudre ton problème.

[koala01]

Salut,

Bonjour,
Si le membre non_public est privé, il n'est pas accessible en dehors de la classe.
Pour qu'il soit accessible depuis les classes dérivées, il faut le passer en protected.

Oui, mais non...

Oui, de fait, si la donnée est en accessibilité protected, cela pourrait permettre aux classes dérivées d'y accéder.

Mais non, ce n'est clairement pas une bonne idée que de passer une donnée dans l'accessibilité protégée.

Car il faut bien comprendre que la classe de base a la responsabilité d'assurer ses invariants, ainsi que ses pré et post conditions.

Si tu permet aux classes dérivées d'aller modifier la valeur d'une donnée sans que les invariants / pré / post conditions ne soient testées de manière systématique lors des modifications de valeur, tu cours forcément le risque que le développeur de la classe dérivée fasse une c...rie en acceptant des valeurs qui n'auraient pas du être acceptées, à cause des invariants imposés par la classe de base.

L'idéal est donc de toujours laisser les données dans l'accessibilité privée et de fournir les comportements adaptés d'interrogation et de modification dans l'accessibilité adéquate, que ce soit privée s'il ne s'agit que de parties de comportements "plus complexes", protégée si les comportements en question doivent être accessibles au travers des fonctions des classes dérivées ou publique si n'importe qui doit pouvoir accéder à ces comportements

Mais pour moi il faut le laisser en private, et ajouter des accesseurs (l'équivalent d'une propriété en C#), protected si besoin, à la classe de base.

Oui, il faut laisser la donnée en accessibilité private,

Oui, un accesseur (getXXX) peut s'avérer utile, qu'il y ait du sens à fournir ce genre de service (pour ce qui a sémantique de valeur comme une distance, une durée, une couleur ou un montant, par exemple), beaucoup moins pour ce qui a sémantique d'entité (comme un réservoir à carburant, par exemple)

Par contre, le mutateur (setXXX), c'est tout de suite beaucoup plus compliqué, car

1. tu ne vas -- très clairement -- pas fournir un mutateur sur une donnée pour laquelle tu n'aurais pas proposé un accesseur (comme la notion de réservoir, sur une voiture)
2. tu places en général une donnée dans l'accessibilité privée pour garder les modifications éventuelles de valeur "sous contrôle". Si tu en viens à donner à l'utilisateur de ta classe la responsabilité de déterminer lui-même la (nouvelle) valeur de ta donnée, tu n'as absolument aucun contrôle sur la valeur qu'il aura définie, et tu as peut-être meilleur temps de laisser ta donnée publique
3. La loi de Déméter nous dit que l'utilisateur d'une donnée de type A qui contiendrait une donnée de type B ne devrait même pas avoir besoin de connaitre l'existence du type B pour pouvoir manipuler son A. Si la présence d'un accesseur (pour autant que la donnée soit fournie sous une forme constante) n'impose pas la connaissance du type B, la présence d'un mutateur rend cette connaissance indispensable, ce qui est en désaccord complet avec Demeter.