Discussion :

[colocolo]

salut;

j'ai une classes GRAPH

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
 
 
class Graph {
 
public:
  int ma[10][10];
  int nb;
 
 
 
  Graph (int );
  int ajouter_sommet();
  void retirer_sommet();
  void ajouter_arc();
  void retirer_arc();
  void Afficher();
  void Succ();
};

je veux utilser l'attribut nb de cette classe dans une autre classe
comment je fait?

merci

[loufoque]

Avec "."

[JeromeBcx]

Avec "."

"...." ?
Tout dépend de la fonctionnalité de la classe qui a besoin de Nb de graph.
Soit CMaclasse qui à besoin de connaître Nb.

1 1ère solution : Graph est un objet de CMaclasse

Code :

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

1
2
3
4
5
6
7
8
9
class CMaclasse
{
public:
  Graph m_mongraph;
  int m_unentierpourlasolution2;
 
public:
  void unefonction();
}

dans la fonction :

Code :

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

1
2
3
4
5
6
 
void CMaclasse::unefonction()
{
  // On utilise Nb de Graph avec :
  int unentier = mongraph.nb;
}

1 2ème solution : Graph et CMaclasse appartienne à une troisième classe

Code :

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

1
2
3
4
5
6
7
8
9
class CTroisiemeClasse
{
public:
  Graph m_mongraph;
  CMaclasse m_maclasse;
 
public:
  void unefonction3emeclasse();
}

dans la fonction :

Code :

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

1
2
3
4
5
6
 
void CTroisiemeClasse::unefonction3emeclasse()
{
  // On utilise Nb de Graph avec :
  m_maclasse.unentierpourlasolution2 = mongraph.nb;
}

Il y a 50 manières de transmettre une valeur d'une classe à l'autre. Dans les deux exemples précédent, c'est vraiment la base.
On peut rajouter et rendre plus propre avec attributs privés, transmission par référence, déclaration dynamique... Toute la puissance de C++ bref.

Donne nous plus d'infos (contexte...)
Puis vas te ballader sur les tutos... pleins de choses interressante pour apprendre le C++.

[Astraya]

Bonjour!

Je ne sait pas si j'ai très bien cerné ton porblème mais pour passer une varibale d'une classe a une autre étant donné que ton nb est public sa ne devrai pas être is compliqué.

Code :

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

1
2
3
4
5
6
7
8
9
10
 
int get_nb(){
return nb;}
 
//ou tout simplement
 
Classenécessitant.var1 = graph.nb
 
//Pour fonction nécessiteuse
fonction(graph.nb);

Après comme dit JeromeBcx tout dépend de ton contexte et de sont utilisation.

[colocolo]

j'ai essayer de faire que ma nouvelle classe qui veux utiliser le "nb" est amie de la class graphe.

class Graph {

public:
int ma[10][10];
int nb;// je veux utiliser nb dans une fonction de la classe comp

Graph (int );
int ajouter_sommet();
void retirer_sommet();
void ajouter_arc();
void retirer_arc();
void Afficher();
void Succ();
friend class comp; // la classe comp et ami de la class graph
};

en complilons tjrs il ya une erreur de ce genre:
error: "nb" was not declared in this scope

[Médinoc]

Montre comment tu essaies de l'utiliser.

[elmcherqui]

tu met la classe sois en heritage ou en classe amie .

[Hurin]

Heu, je suis pas sûr, mais je crois qu'il veut voir comment utiliser une classe friend,...

En fait le seul avantage (à ma connaissance) de déclarer une classe friend, c'est de permettre à la classe déclaré friend d'avoir accès à tous les attributs de ta classe, mais pour qu'elle puisse s'en servir, il faut bien lui dire quelle instance de la classe elle va utiliser,...

Donc, en simple, ça donne un truc comme ça:

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
33
class une_class;
class another_class;
class une_class
{
	friend another_class;
private:
	int nbr;
public:
	une_class(){ nbr=5;}
	void Affichage(){Console::WriteLine("mon nbr =");
	Console::WriteLine(nbr);}
 
} ;
class another_class
{	
public:
	void Affichage(une_class A){Console::WriteLine("le nbr de la classe qui m'a déclaré en ami est :");
	Console::WriteLine(A.nbr);
	}
 
};
 
int _tmain()
{
    // TODO: Please replace the sample code below with your own.
	une_class class1;
	another_class class2;
	class1.Affichage();
	class2.Affichage(class1);
	Console::ReadLine();
 
	return 0;
}

En espérant que c'est pas HS,...

[befalimpertinent]

j'ai essayer de faire que ma nouvelle classe qui veux utiliser le "nb" est amie de la class graphe.

Sauf cas particulier (plutôt rare finalement) essayes de ne pas trop utiliser friend. Utilises plutôt des getter/setter à la place.
Crois moi le mot clé friend peut paraitre magic et répondre à ce que tu attend mais à terme c'est un très mauvais choix dans ton cas.
Pour plus d'info cf

[Davidbrcz]

Sauf cas particulier (plutôt rare finalement) essayes de ne pas trop utiliser friend. Utilises plutôt des getter/setter à la place.

Friend c'est aml (sauf certains cas)
getter/setter : c'est mal aussi !
Car tu expose ton interface privé !
On encapsule des comportements, pas des données.

[Médinoc]

SI les getters/setters étaient si mal que ça, pourquoi a-t-on inventé les Propriétés sur des plate-formes comme .Net et COM?

[coyotte507]

Honnêtement je pense qu'il faut arrêter de dire que telle ou telle chose est mauvaise ou non.

Chacun programme comme il le sent, il n'est pas interdit d'utiliser des char[] ni de l'héritage multiple, ni un sprintf, ni même de programmer en C++ sans la STL, en utilisant les nouvelles possibilités de la programmation objet du C++ avec des fonctions du C...

Il n'est pas non plus interdit de mettre tous les membres en public pour ne pas avoir de setter/getter à utiliser, il n'est pas interdit de ne pas respecter à 100% le principe de l'encapsulation.

[koala01]

Salut,

Honnêtement je pense qu'il faut arrêter de dire que telle ou telle chose est mauvaise ou non.

Chacun programme comme il le sent, il n'est pas interdit d'utiliser des char[] ni de l'héritage multiple, ni un sprintf, ni même de programmer en C++ sans la STL, en utilisant les nouvelles possibilités de la programmation objet du C++ avec des fonctions du C...

Il n'est pas non plus interdit de mettre tous les membres en public pour ne pas avoir de setter/getter à utiliser, il n'est pas interdit de ne pas respecter à 100% le principe de l'encapsulation.

Si, dans l'absolu, tu as (en partie) raison, en pratique, c'est clairement une autre histoire.

Si on insiste généralement sur le fait de préférer les capacités offertes par le C++ et par ses classes à toute possibilité équivalente héritée du C, c'est, avant tout parce que l'on se base sur les faits certain que:

1. Les possibilités du C++ et de ses classes fonctionnent de manière généralement bien plus sécurisante que l'ensemble des fonctions équivalentes issues du C
2. Même en étant particulièrement doué, tu mettra longtemps à faire seul (et sans doute moins bien) ce que de nombreuses personnes ont fait, en longtemps aussi, il faut quand même le signaler.
3. Il est, finalement, bien plus facile de se rappeler d'une vingtaine de classes - même si elles disposent chacune d'une vingtaine de méthodes - en sachant à quoi elles servent, mais en étant sûr que leur implémentation est correcte et permet d'assurer une sécurisation suffisante du code (du point de vue des dépassements de capacités ou des fuites mémoire, par exemple) que d'avoir à gérer par soi-même l'ensemble des problèmes que ces classes et méthodes permettent d'éviter.
   
   D'autant plus que la plupart des classes ne présentent généralement qu'un nombre assez restreint de méthodes d'usage réellement courent (pour les autres, en connaissant les bons sites, et en sachant "que telle classe permet tel comportement", il est facile de retomber sur la méthode qui le met en oeuvre )
4. Les mauvaise habitudes sont généralement tout à la fois plus faciles à prendre et plus difficiles à perdre que les bonnes. Au final, plus tu laisse quelqu'un s'enfermer dans un carcan de mauvaise habitudes, plus il lui sera difficile d'envisager de les abandonner au profit d'habitudes dont il peut très bien ne pas mettre l'efficacité en doute

D'un autre côté, rien ne t'empêche d'essayer de couper une bûche avec un couteau à steak ou une lime à ongle... Mais tu avoueras qu'il est généralement plus facile de le faire avec la scie adaptée ou avec une bonne tronçonneuse .

Dans tous les métiers, un des credo est que "le bon ouvrier utilise les bons outils" (sous entendu: les mieux adaptés à la situation).

Les outils du programmeur, ce sont les langages.

De manière générale, on peut distinguer trois grands types de langages:

• les langages procéduraux
• les langages fonctionnels
• les langages (orientés) objets

Chacun de ces types de langage est susceptible d'être "particulièrement" adapté à une situation donnée, et, au sein de ces différents types, il est souvent possible d'affiner le critère de sélection en vue de décider quel langage permettra d'arriver le plus facilement au but que l'on s'est fixé.

Sans vouloir relancer un quelconque débat sur le thème du "quel langage est le meilleur", il faut bien être conscient que le C++ est clairement dans la catégorie des "langages (orientés) objets", même s'il a "le bon gout" de laisser la possibilité de choisir de travailler en procédural pur et simple.

Cependant, il n'est pas rare de constater que, si tu décide de ne pas utiliser les capacités "objet" du C++, c'est qu'il existe un langage purement procédural (ou, pourquoi pas, fonctionnel) qui serait sans doute bien mieux adapté au but que tu poursuis

Il est donc logique que l'on insiste pour inciter autant que faire se peut les "nouveaux venus" à utiliser le C++ pour ce qu'il est: un langage objet disposant de classes de nature à faciliter grandement le travail dans une grande majorité de situations.

La différence qui existe entre les langages purement procéduraux et les langages dits "orientés objets" (ou "objets", pur et dur), c'est qu'ils permettent de s'abstraire des données réelles contenues dans les structures inévitables de données pour s'intéresser en priorité aux messages qu'elles véhiculent (qu'elles émettent ou qu'elles reçoivent)

L'un des avantages immédiat est que le code qui utilise une structure de données conçue dans une optique objet sera plus pérenne que le code qui utilise une structure tout à fait équivalente conçue dans une optique purement procédurale.

L'inconvénient majeur, car, rien n'est jamais ni tout blanc ni tout noir, est que cela nécessite sans doute une réflexion plus profonde en période de conception.

En conclusion, je suis tout à fait d'accord avec toi quand tu réprouve les règles édictées "à l'emporte pièces" du genre de

l'amitié, c'est mal

tant il est vrai que, l'amitié est parfois utile - si pas nécessaire ou indispensable - dans certaines situations, même s'il reste important à veiller à ce que l'accès qu'elle autorise soit le moins intrusif possible ou du genre de

les getters et setters, c'est mal

ne serait-ce que parce que je préfère utiliser les terme "mutateurs" et "accesseurs" pour indiquer clairement qu'il ne s'agit pas *forcément* d'un simple return x; ou d'un simple x=valeur; mais qu'ils peuvent faire autre chose avant (ou après), mais aussi parce que j'estime que la décision de les proposer doit être évaluée en fonction des circonstances.

Par contre, j'ai beaucoup plus de mal à être d'accord avec toi quand tu t'élève contre le principe de l'encapsulation.

Je ne veux pas verser dans "l'encapsulation à tout prix", mais, comme l'encapsulation est quand même l'un des piliers du paradigme orienté objet, je reste persuadé qu'il reste préférable de ne rendre publics que les membres dont il apparait clairement qu'il n'est pas possible/opportun/sensé de les déclarer protégés ou privés.

[coyotte507]

Koala01,

je suis totalement d'accord avec ton post.

Je ne m'élève pas du tout contre le principe de l'encapsulation, je voulais dire que quelques rares fois on pouvait avoir envie de passer outre et d'accéder à des données private. Je ne critique pas l'existence du mot-clé private ni du mot-clé protected.

On encapsule des comportements, pas des données.

D'ailleurs à y réfléchir, pour moi encapsuler c'était cacher des données, je crois que j'ai parlé sans savoir

Enfin, je ne veux pas entrer dans un débat, je suis d'accord avec toi.

[Davidbrcz]

J'y suis peut être allé un peu fort dans mon 1er message .
Donc, je reprend ;
L'amitié c'est le mal dans 90% des cas car elle est mal utilisé.
Pour moi, l'amitié ne devrait être utilisé que lorsque l'on doit scinder une classe en 2 pour X raisons ou dans des situations de ce genre.

Les "mutateurs" et "accesseurs" sont peut être un peu moins le mal que l'amitié mais reste néanmoins assez mal utilisé dans une bonne partie des cas. (moi même des fois, j'en utilise et je sais alors que quelque chose ne va pas , mais comme c'est du code perso donc j'mef un peu ^^)

En effet, même s'il permettent une vérification des données fournit dans le cas des mutateurs, il n'en reste pas moins qu'ils exposent l'interface privée d'une classe a ses utilisateurs. De fait, si la classe change, le code qui l'utilise risque de devoir changer.

Dès lors, il faut priviligier une encapsulation des comportements dans les classes de telle sorte que même si on change la manière de réaliser ce comportement, l'utilisateur n'en sache rien.

Enfin, comme la dit Koala, il faut aussi savoir quand même certain membre public. Néanmoins ces cas sont assez rare et devrait être - a mon avis - justifiés à chaque fois.

Edit: lisez ce blog : http://blog.emmanueldeloget.com/ .C'est une vrai mine d'or sur la conception est ses principes.

[koala01]

En fait, tout dépend de si tes classes sont réellement des objet au sens propre (des objets pour lesquels on attend qu'il fournissent un certain nombre de services) ou s'il s'agit "tout simplement" de sécuriser les PODS (Plain Old Data Structures)...

Si, et c'est conseillé, on n'a à faire qu'à des classes dont le but est de fournir certains services, les mutateurs deveinnent souvent inutiles, et, pour ce qui est de accesseurs, il s'agit de savoir s'il est sensé de faire que la classe fournisse le service de donner cette valeur.

S'il s'agit de PODS, (exemple: un point 3D ), il deveint tout à fait cohérent de fournir des mutateurs et des accesseurs, sur des membres privés, de manière à permettre une meilleure pérennité des codes qui utilisent la classe...

On voit donc bien qu'aucune règle trop ferme en la matière devient rapidement impossible à respecter

[JeromeBcx]

bonjour c'est encore moi j'ai fait une petite erreur avant
je vous donne un exemple de programme a la place qui
j'espère pourra mieux vous aidez.

brother2007,
outre un décalage entre votre post et celui avisé de koala01, votre proposition ne fournit qu'une réponse dans un contexte particulier.

Pour trouver la réponse, cela ne dépend pas de la technologie (objet, héritage, amitié, accesseur, ....), mais du contexte d'utilisation...
Le problème vient du désir d'accéder à un attribut nb d'une classe A par une autre B. Avec seulement ces informations, il est très difficile de répondre au problème.
En effet les quelques lignes suivantes illustres plusieurs solutions, non exhaustives...
-Si la classe B propose de répondre à une problématique proche de celle de A (B plus spécifique A, ex: A=véhicule, B=moto) alors B devrait hériter de A.
-Si la classe B répond à une autre problématique, il faudrait passer l'attribut nb en paramètre d'une fonction ou constructeur de B.
-Enfin, la classe B propose des fonctionnalités plus globales que A, qui représente alors une sous fonctionnalité de B (équivalent à l'exemple de brother2007). Dans ce cas, A pourrait être un attribut de B, et nb serait accessible par le biais d'une méthode "get", ou plus généralement "accesseurs" (cf. Davidbrcz), et non pas directement accessible par attribut public.