j'aimerai en savoir un peu plus sur les "règles" ou plutôt "coutumes"
de programmation objet c++ (simple). En particulier, j'ai entendu dire
qu'on ne devait pas mettre de "cout/cin" dans les classes, que cela
devait etre des stream...
Alors j'ai deux exemples :
1) j'ai une classe A qui représente un objet, regroupant un ensemble de
caractéristiques propres. Disons que j'ai besoin au cours de mon code
"d'afficher" l'ensemble de ces caractéristiques a l'écran, il parait
assez intuitif de surcharger l'opérateur '<<' plutôt que de coder une
méthode 'afficher', et ensuite faire cout << obj_A;
2) maintenant, supposons que j'ai besoin, en plus de l'affichage d'un
objet a l'écran, d'afficher des trucs "indépendant" vis a vis de
l'objet, par exemple j'ai besoin pour une méthode X de ma classe A, de
demander a l'utilisateur d'entrer une valeur, est-ce mal de faire :
cout << entrer la valeur X : ";
cin >> x;
dans la méthode de ma classe A ??
si oui, doit-on gérer tout ce qui est affichage d'une manière
indépendante des méthodes d'une classe ? par exemple avec une classe
"affichage" etc...
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Alexandre
j'aimerai en savoir un peu plus sur les "règles" ou plutôt "coutumes" de programmation objet c++ (simple). En particulier, j'ai entendu dire qu'on ne devait pas mettre de "cout/cin" dans les classes, que cela devait etre des stream...
C'est préférable car plus général.
Alors j'ai deux exemples :
1) j'ai une classe A qui représente un objet, regroupant un ensemble de caractéristiques propres. Disons que j'ai besoin au cours de mon code "d'afficher" l'ensemble de ces caractéristiques a l'écran, il parait assez intuitif de surcharger l'opérateur '<<' plutôt que de coder une méthode 'afficher', et ensuite faire cout << obj_A;
Correct.
2) maintenant, supposons que j'ai besoin, en plus de l'affichage d'un objet a l'écran, d'afficher des trucs "indépendant" vis a vis de l'objet, par exemple j'ai besoin pour une méthode X de ma classe A, de demander a l'utilisateur d'entrer une valeur, est-ce mal de faire :
cout << entrer la valeur X : "; cin >> x;
dans la méthode de ma classe A ??
C'est pas très pratique... Il faut mieux que tu es une méthode dans ta class A qui modifie x, par un flux par exemple : istream& operator>>(istream& flux, A& a) { flux>>a.x; return flux; }
et dans ton programme (ou classe, ou fonction...) qui utilises le A, c'est là que tu fais l'affichage avec le cout : A a; cout<<"entrer la valeur X :"; cin>>a;
si oui, doit-on gérer tout ce qui est affichage d'une manière indépendante des méthodes d'une classe ? par exemple avec une classe "affichage" etc...
C'est préférable, ça évitera de tout refaire si - tu dois changer les messages pour être en anglais - tu dois passer d'une appli "console" a une appli "fenetre" - tu veux écrire dans un fichier plutot que sur la console etc...
De manière générale, quand on programme, il faut essayer au maximum qu'une fonction fasse UNE tache, qu'un objet est UNE utilité, etc...
j'aimerai en savoir un peu plus sur les "règles" ou plutôt "coutumes"
de programmation objet c++ (simple). En particulier, j'ai entendu dire
qu'on ne devait pas mettre de "cout/cin" dans les classes, que cela
devait etre des stream...
C'est préférable car plus général.
Alors j'ai deux exemples :
1) j'ai une classe A qui représente un objet, regroupant un ensemble de
caractéristiques propres. Disons que j'ai besoin au cours de mon code
"d'afficher" l'ensemble de ces caractéristiques a l'écran, il parait
assez intuitif de surcharger l'opérateur '<<' plutôt que de coder une
méthode 'afficher', et ensuite faire cout << obj_A;
Correct.
2) maintenant, supposons que j'ai besoin, en plus de l'affichage d'un
objet a l'écran, d'afficher des trucs "indépendant" vis a vis de
l'objet, par exemple j'ai besoin pour une méthode X de ma classe A, de
demander a l'utilisateur d'entrer une valeur, est-ce mal de faire :
cout << entrer la valeur X : ";
cin >> x;
dans la méthode de ma classe A ??
C'est pas très pratique... Il faut mieux que tu es une méthode dans ta class
A qui modifie x, par un flux par exemple :
istream& operator>>(istream& flux, A& a)
{
flux>>a.x;
return flux;
}
et dans ton programme (ou classe, ou fonction...) qui utilises le A, c'est
là que tu fais l'affichage avec le cout :
A a;
cout<<"entrer la valeur X :";
cin>>a;
si oui, doit-on gérer tout ce qui est affichage d'une manière
indépendante des méthodes d'une classe ? par exemple avec une classe
"affichage" etc...
C'est préférable, ça évitera de tout refaire si
- tu dois changer les messages pour être en anglais
- tu dois passer d'une appli "console" a une appli "fenetre"
- tu veux écrire dans un fichier plutot que sur la console
etc...
De manière générale, quand on programme, il faut essayer au maximum qu'une
fonction fasse UNE tache, qu'un objet est UNE utilité, etc...
j'aimerai en savoir un peu plus sur les "règles" ou plutôt "coutumes" de programmation objet c++ (simple). En particulier, j'ai entendu dire qu'on ne devait pas mettre de "cout/cin" dans les classes, que cela devait etre des stream...
C'est préférable car plus général.
Alors j'ai deux exemples :
1) j'ai une classe A qui représente un objet, regroupant un ensemble de caractéristiques propres. Disons que j'ai besoin au cours de mon code "d'afficher" l'ensemble de ces caractéristiques a l'écran, il parait assez intuitif de surcharger l'opérateur '<<' plutôt que de coder une méthode 'afficher', et ensuite faire cout << obj_A;
Correct.
2) maintenant, supposons que j'ai besoin, en plus de l'affichage d'un objet a l'écran, d'afficher des trucs "indépendant" vis a vis de l'objet, par exemple j'ai besoin pour une méthode X de ma classe A, de demander a l'utilisateur d'entrer une valeur, est-ce mal de faire :
cout << entrer la valeur X : "; cin >> x;
dans la méthode de ma classe A ??
C'est pas très pratique... Il faut mieux que tu es une méthode dans ta class A qui modifie x, par un flux par exemple : istream& operator>>(istream& flux, A& a) { flux>>a.x; return flux; }
et dans ton programme (ou classe, ou fonction...) qui utilises le A, c'est là que tu fais l'affichage avec le cout : A a; cout<<"entrer la valeur X :"; cin>>a;
si oui, doit-on gérer tout ce qui est affichage d'une manière indépendante des méthodes d'une classe ? par exemple avec une classe "affichage" etc...
C'est préférable, ça évitera de tout refaire si - tu dois changer les messages pour être en anglais - tu dois passer d'une appli "console" a une appli "fenetre" - tu veux écrire dans un fichier plutot que sur la console etc...
De manière générale, quand on programme, il faut essayer au maximum qu'une fonction fasse UNE tache, qu'un objet est UNE utilité, etc...
C'est pas très pratique... Il faut mieux que tu es une méthode dans ta class A qui modifie x, par un flux par exemple : istream& operator>>(istream& flux, A& a) { flux>>a.x; return flux; }
et dans ton programme (ou classe, ou fonction...) qui utilises le A, c'est là que tu fais l'affichage avec le cout : A a; cout<<"entrer la valeur X :"; cin>>a;
alors d'accord, mais comment faire dans le cas de variables que je qualifierai "d'intermédiaires" ou de "temporaires" ? je veux parler de ces variables qui ne sont pas des objets mais qui sont justes déclarées dans une méthode, et dont la valeur dépend d'une entrée de l'utilisateur !
exemple :
j'ai besoin au cours de mon programme d'une valeur entrée par l'utilisateur, oui ou non, qui est matérialisée par 'o' ou 'n', alors j'ai dans ma classe une méthode qui est :
elle retourne le caractère après s'etre assuré qu'il était bon, ce caractère est ensuite testé dans une autre méthode pour savoir si l'utilisateur a dit oui, ou non. En aucune façon ce caractère est présent dans la déclaration de la classe, ça n'est ni un objet, ni un membre d'objet... mais juste une... variable intermédiaire, temporaire, utile au déroulement...
comment utiliser la surcharge de '>>' dans ces condition ?
si oui, doit-on gérer tout ce qui est affichage d'une manière indépendante des méthodes d'une classe ? par exemple avec une classe "affichage" etc...
C'est préférable, ça évitera de tout refaire si - tu dois changer les messages pour être en anglais - tu dois passer d'une appli "console" a une appli "fenetre" - tu veux écrire dans un fichier plutot que sur la console etc...
De manière générale, quand on programme, il faut essayer au maximum qu'une fonction fasse UNE tache, qu'un objet est UNE utilité, etc...
je comprends bien l'utilité, mais je ne vois pas vraiment comment l'appliquer.
C'est pas très pratique... Il faut mieux que tu es une méthode dans ta class
A qui modifie x, par un flux par exemple :
istream& operator>>(istream& flux, A& a)
{
flux>>a.x;
return flux;
}
et dans ton programme (ou classe, ou fonction...) qui utilises le A, c'est
là que tu fais l'affichage avec le cout :
A a;
cout<<"entrer la valeur X :";
cin>>a;
alors d'accord, mais comment faire dans le cas de variables que je
qualifierai "d'intermédiaires" ou de "temporaires" ? je veux parler de
ces variables qui ne sont pas des objets mais qui sont justes déclarées
dans une méthode, et dont la valeur dépend d'une entrée de
l'utilisateur !
exemple :
j'ai besoin au cours de mon programme d'une valeur entrée par
l'utilisateur, oui ou non, qui est matérialisée par 'o' ou 'n', alors
j'ai dans ma classe une méthode qui est :
elle retourne le caractère après s'etre assuré qu'il était bon, ce
caractère est ensuite testé dans une autre méthode pour savoir si
l'utilisateur a dit oui, ou non. En aucune façon ce caractère est
présent dans la déclaration de la classe, ça n'est ni un objet, ni un
membre d'objet... mais juste une... variable intermédiaire, temporaire,
utile au déroulement...
comment utiliser la surcharge de '>>' dans ces condition ?
si oui, doit-on gérer tout ce qui est affichage d'une manière
indépendante des méthodes d'une classe ? par exemple avec une classe
"affichage" etc...
C'est préférable, ça évitera de tout refaire si
- tu dois changer les messages pour être en anglais
- tu dois passer d'une appli "console" a une appli "fenetre"
- tu veux écrire dans un fichier plutot que sur la console
etc...
De manière générale, quand on programme, il faut essayer au maximum qu'une
fonction fasse UNE tache, qu'un objet est UNE utilité, etc...
je comprends bien l'utilité, mais je ne vois pas vraiment comment
l'appliquer.
C'est pas très pratique... Il faut mieux que tu es une méthode dans ta class A qui modifie x, par un flux par exemple : istream& operator>>(istream& flux, A& a) { flux>>a.x; return flux; }
et dans ton programme (ou classe, ou fonction...) qui utilises le A, c'est là que tu fais l'affichage avec le cout : A a; cout<<"entrer la valeur X :"; cin>>a;
alors d'accord, mais comment faire dans le cas de variables que je qualifierai "d'intermédiaires" ou de "temporaires" ? je veux parler de ces variables qui ne sont pas des objets mais qui sont justes déclarées dans une méthode, et dont la valeur dépend d'une entrée de l'utilisateur !
exemple :
j'ai besoin au cours de mon programme d'une valeur entrée par l'utilisateur, oui ou non, qui est matérialisée par 'o' ou 'n', alors j'ai dans ma classe une méthode qui est :
elle retourne le caractère après s'etre assuré qu'il était bon, ce caractère est ensuite testé dans une autre méthode pour savoir si l'utilisateur a dit oui, ou non. En aucune façon ce caractère est présent dans la déclaration de la classe, ça n'est ni un objet, ni un membre d'objet... mais juste une... variable intermédiaire, temporaire, utile au déroulement...
comment utiliser la surcharge de '>>' dans ces condition ?
si oui, doit-on gérer tout ce qui est affichage d'une manière indépendante des méthodes d'une classe ? par exemple avec une classe "affichage" etc...
C'est préférable, ça évitera de tout refaire si - tu dois changer les messages pour être en anglais - tu dois passer d'une appli "console" a une appli "fenetre" - tu veux écrire dans un fichier plutot que sur la console etc...
De manière générale, quand on programme, il faut essayer au maximum qu'une fonction fasse UNE tache, qu'un objet est UNE utilité, etc...
je comprends bien l'utilité, mais je ne vois pas vraiment comment l'appliquer.
ça dépend quel est le bon de ton objet C_Interface. Si c'est une classe chargées des interactions utilisateur, l'emploi de cout et cin est tout à fait normal ! Mais est-ce le cas ?
ça dépend quel est le bon de ton objet C_Interface.
Si c'est une classe chargées des interactions utilisateur, l'emploi de cout
et cin est tout à fait normal !
Mais est-ce le cas ?
ça dépend quel est le bon de ton objet C_Interface. Si c'est une classe chargées des interactions utilisateur, l'emploi de cout et cin est tout à fait normal ! Mais est-ce le cas ?
Nicolas Aunai
"Alexandre" a couché sur son écran :
ça dépend quel est le bon de ton objet C_Interface. Si c'est une classe chargées des interactions utilisateur, l'emploi de cout et cin est tout à fait normal ! Mais est-ce le cas ?
beh en fait, j'ai programmé un ptit jeu à n joueur au tour par tour, et j'ai en gros :
une classe C_Joueur et une classe C_Interface
la classe C_Interface gère tout ce qui touche aux N joueur, elle comprend par exemple le tableau de joueur, les scores totaux, une méthode qui fait "jouer" un joueur... et s'occupe en gros de l'interface du jeu... c'est un peu vague.
ça dépend quel est le bon de ton objet C_Interface.
Si c'est une classe chargées des interactions utilisateur, l'emploi de cout
et cin est tout à fait normal !
Mais est-ce le cas ?
beh en fait, j'ai programmé un ptit jeu à n joueur au tour par tour, et
j'ai en gros :
une classe C_Joueur
et une classe C_Interface
la classe C_Interface gère tout ce qui touche aux N joueur, elle
comprend par exemple le tableau de joueur, les scores totaux, une
méthode qui fait "jouer" un joueur... et s'occupe en gros de
l'interface du jeu... c'est un peu vague.
ça dépend quel est le bon de ton objet C_Interface. Si c'est une classe chargées des interactions utilisateur, l'emploi de cout et cin est tout à fait normal ! Mais est-ce le cas ?
beh en fait, j'ai programmé un ptit jeu à n joueur au tour par tour, et j'ai en gros :
une classe C_Joueur et une classe C_Interface
la classe C_Interface gère tout ce qui touche aux N joueur, elle comprend par exemple le tableau de joueur, les scores totaux, une méthode qui fait "jouer" un joueur... et s'occupe en gros de l'interface du jeu... c'est un peu vague.
