Discussion :

[Linu6]

Bonjour

Voici mon problème.

J'ai deux class,on va les appeler:

Code :

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

classe A

et

Code :

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

classe B

class B contient une methode quelconque.

Je veux savoir s'il est possible que l'objet de class A puisse utiliser la methode déclarée dans B, sans passer par l'héritage.

voici ce que je veux obtenir sans avoir recours à l'héritage (si possible) mais uniquement utiliser les declarations d'amitié.

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
 
class A
{
....
public:
 
....
};
 
 
class B
{
....
public:
// friend class A?
void methode();
};
 
int main()
{
A a1;
B b1;
 
a1.methode(); // je souhaite faire cette opération, mais je ne sais si je puis //m'en passer de l'héritage, pour cela, peut on y parvenir en manipulant //"l'outil" friend?
 
 
return 0;
}

merci

[zintelix3d]

Slt , http://ltiwww.epfl.ch/pub/fra/SyncC/TextCpp3.html

[nikko34]

nope, le mot clé friend ne fait pas ce que tu penses.

Mais tu as d'autres choix que l'héritage, tu peux aussi faire des compositions. Peut être qu'il vaudrait mieux que tu nous expliques concrètement pourquoi et ce que tu veux faire, parce que là c'est pas clair.

Pourquoi A voudrait utiliser une méthode de B ? c'est une méthode normale ou statique? Pourquoi cette méthode n'est pas dans A?

[NewbiZ]

Une méthode de B nécessite forcément une instance de B.

Pour avoir cette instance depuis A,
Soit A fait office d'instance de B (héritage)
Soit ta méthode prend en paramètre une instance de B.

[poukill]

Une instance d'une classe B qui veut accéder à une méthode de A, ça sent le problème de conception à plein nez!
Pourquoi ne pas déclarer ta méthode comme une fonction libre plutôt? Elle serait accessible partout...

[Linu6]

avec un exemple plus clair ....ça sera plus claire.

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
 
class Comment;
 
class Prof
{
....
public:
friend class Comment;
void commenter(Comment& com){ com.putCom(); }
....};
 
class Comment
{
.....
public:
friend class Prof;
void putCom();
...
}

Voila, j'ai un code qui ressemble (en gros) à ça, et pourtant j'ai 3 erreurs:

Code :

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

1
2
3
 
main.cpp: In member function `void Prof::Commenter(Comment&)':
main.cpp:427: error: `putCom' undeclared (first use this function)

... or, le problème c'est que 'putCom' est déclaré un peu plus loin et la class Comment est bel est bien indiqué tout en haut..

[koala01]

Salut,

Il faut savoir que, s'il est très doué pour beaucoup de choses, le compilateur C++ est un parfait idiot quand il s'agit de lire le code source.

En effet, il est comme toi quand tu lis un livre, et - tout comme tu ne sais a priori pas ce qui se passe à la page 11 quand tu n'a lu que les 10 premières pages (et cela ne veut absolument pas dire que tu sois un parfait idiot... je ne me permettrait pas ce genre de jugement ) - le compilateur ne connait que ce qu'il a déjà rencontré dans les lignes qui précèdent.

Aussi, si le code pose problème, ce n'est pas à cause d'une amitié mal placée, c'est simplement parce que quand il rencontre ton appel à com.putCom(); dans la méthode commenter, il ne sait tout simplement pas... que les commentaires disposent d'une méthode ... putComm.

Le simple fait de placer la définition de ta classe commentaire avant celle de la classe Prof ou de séparer l'implémentation de la méthode Commenter de sa déclaration suffirait à résoudre le problème .

En outre, il faut éviter de déclarer des amitiés à tord et à travers.

En effet, quand tu déclare la classe Comment amie de la classe Prof, cela revient à dire au compilateur que

la classe Prof fait suffisemment confiance à la classe Comment pour lui permettre d'accéder à tous ses éléments les plus personnels (tout ce que l'on a placé dans les accessibilités protected ou private )

Si tu utilise l'amitié à bon escient et de manière très réfléchie, elle peut te permettre d'améliorer l'encapsulation de tes données, en permettant à une classe ou à une fonction membre de classe d'accéder à certaines données sans te placer dans l'obligation d'exposer ces données - ou les méthodes qui permettent d'y accéder/de les modifier - à la vue de tous.

Par contre, chaque amitié que tu déclare risque de ... t'inciter à accéder directement à une valeur particulière de la classe au lieu de passer par les méthodes qui y donnent accès.

Cela finit par nuire très fortement à l'encapsulation car, le but premier de déclarer une valeur avec une accessibilité private ou protected est... d'éviter que quelqu'un n'aille essayer d'accéder ou de modifier cette valeur directement, et donc de te laisser la possibilité de décider d'une "autre représentation en mémoire" pour cette valeur, en t'assurant que le nombre de modifications à apporter du fait de cette décision sera très limité.

Avec le code que tu présente, tu tombe dans l'excès étant donné que la classe Prof peut se contenter de l'accès à la méthode putCom qui est publique dans la classe Comment et que, d'un autre coté, la classe Comment peut se contenter des méthodes publiques de la classe Prof

Au passage, j'ose te proposer d'essayer de garder une certaine "symétrie" dans les noms de tes fonctions et de tes classes.

Tu mélange allègrement le francais ("Prof") et l'anglais (Comment), et tu commence parfois tes méthodes par une minuscule (putComm) et d'autres fois par des majuscules (Commenter)...

Il n'y a aucune convention obligatoire en ce qui concerne la manière d'écrire le code, mais il semble quand même opportun - pour ne pas dire très utile - de décider d'une convention de nommage et de s'y tenir dans l'ensemble du projet:

N'oublie jamais qu'un code source n'est jamais qu'un fichier texte (du moins jusqu'à présent) et qu'il doit être lu bien plus souvent qu'il est écrit ou compilé.

Il n'est donc absolument pas exclu que le code soit, à l'occasion, modifié avec un outil ne disposant ni de la coloration syntaxique ni de la complétion automatique tel que le simple "bloc note" sous windows, et seules des conventions clairement établies et scrupuleusement respectées sont de nature à assurer la facilité d'une modification dans de telles circonstances.