Discussion :

[Disixlis]

Bonjour à tous ! Actuellement j'ai codé un petit system qui enregistre des livres, les trie etc...
Comme je n'ai pas beaucoup de temps et que j'ai besoin d'avoir rapidement un logiciel fonctionnel, les enregistrement de livres se font via la console bien que plus tard cela se fera via une GUI.
J’aimerais juste savoir si il est possible de passé en argument à un setter les données récupéré via std::cin sans passé par une variable. C'est à dire que j'aimerais que ceci :

Code :

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

1
2
3
4
5
6
7
8
 
 
Book book;
std::string name;
 
std::cout << "Entrez sont nom : ";
std::getline( std::cin, name );
book.setName(name);

ce transforme en quelque chose comme ça :

Code :

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

1
2
3
4
5
6
 
 
Book book;
 
std::cout << "Entrez sont nom : ";
book.setName(?std::cin?);

Je n'ai jamais fait de choses comme ceci mais pour une fois j'aimerais évité d'avoir des variables un peu useless qui ne servent qu'une fois.
Je ne sais pas si c'est possible mais merci de m'indiquer comment faire ci ça l'est et bien sur, l'entrée de l'utilisateur peut contenir des espaces.

Je vous remercie !

PS : J'ai chercher sur Google et je n'est pas trouvé ce qui m'intéressé

[Médinoc]

Sans passer par une variable, je ne crois pas, mais tu peux toujours cacher cela dans un wrapper:

Code C++ :

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

1
2
3
4
5
6
std::string MyGetLine()
{
	std::string line;
	std::getline(std::cin, line);
	return line;
}

Code C++ :

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

book.setName(MyGetLine());

[Disixlis]

J'avais pensé à ça ( D'ailleurs google ma donner la même réponse :p ) mais je cherche quand même si c'est possible sans wrapper, sans variables, sans rien x). Mais si tu me dit qu'il n'est vraiment pas possible de le faire alors sujet résolue ?

[oodini]

Tu es obligé de le faire en deux étapes parce qu'il y a une encapsulation qui bloque la libre transmission de la valeur lue dans le flux au membre de Book qui doit contenir le nom.
Tu ne peux pas demander le beurre ou l'argent du beurre.

Ou alors, ta classe gérant l'IHM peut être rendue amie de la classe Book. Et dans ce cas là, tu pourras utiliser directement l'opérateur >>.

[Hassan.]

Si Book::name est public tu pourras faire std::cin directement dessus, mais dans ce cas tu va te priver des avantages qu'offrent les getters/setters (validation ou lecture/écriture seule par exemple) :

Code :

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

1
2
3
4
5
 
Book book;
 
std::cout << "Entrez sont nom : ";
std::cin >> book.name;

Il n'y a pas (trop) de mal à utiliser des variables temporaires à mon avis. Tu pourrais par exemple l'appeler "input" au lieu de "name" et l'utiliser à chaque fois que tu as besoin de lire de l'input.

[Disixlis]

Oui sauf que là tu brise une régle de base mais des plus important, aucun attribut ne doit être public. Je trouve que c'est le mal moi :p
Finalement je suis passé sous GUI donc sujet résolue, et c'était juste petite question pour voir si c'était possible proprement, donc je vais pas passé par des bidouillages x).

Merci de vos réponses

[koala01]

Salut,

Ceci dit, la seule idée de vouloir changer le nom (l'auteur, l'éditeur, ou à peu près n'importe quoi) d'un livre est -- à mon avis du moins -- un non sens total : une fois qu'il a été écrit, son titre, son auteur et son texte n'ont absolument plus besoin de changer et font, d'une certaine manière, partie intégrante de ce qui permet d'identifier chaque livre de manière unique et non ambigüe

L'idée derrière cette remarque est que tu devrais fournir un constructeur prenant ce genre d'information comme paramètre, et attendre -- en bon utilisateur du paradigme OO -- d'avoir toutes les informations nécessaires avant d'essayer de construire ton objet, pour qu'il soit réellement identifiable de manière strictement unique

Du coup, au lieu d'avoir un code (très beurk) proche de

Code :

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

1
2
3
4
Book b;
b.setName(unTitre);
b.setAutor(unAuteur;
/* autres parties suceptibles de servir à l'identification*/

tu te retrouverais avec un code proche de

Code :

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

Book b(unTitre, unAuteur,/* autres parties suceptibles de servir à l'identification*/);

avec l'énorme avantage que, une fois que le livre aura été créé, l'utilisateur qui a demandé sa création n'aura "plus rien à faire" avant de pouvoir l'utliser

[Disixlis]

Bien évidemment j'aurais fait ça si ce logiciel n'est pas pour une personne âgée qui fait souvent des erreurs et doit donc modifier certains livres

[dragonjoker59]

Y a pas besoin d'être une personne agée, quand on voit les bourdes qu'ils peuvent faire à la BNF...

[koala01]

Bien évidemment j'aurais fait ça si ce logiciel n'est pas pour une personne âgée qui fait souvent des erreurs et doit donc modifier certains livres

Mais, ca, bien que ce soit effectivement un problème qu'il s'agisse de prendre en compte, cela ne doit pas te servir de justification pour déroger à la loi de Déméter

Parce qu'il arrive beaucoup trop souvent à mon gout que l'on parte du principe (qui est toujours vérifié ) que "l'utilisateur est un imbécile idiot" pour décider de déroger à un principe quelconque, et "merde pour les problèmes que cela nous occasionnera par la suite (de toutes manière, ce sera sans doute à mon successeur d'y remédier)"

Or, il est toujours possible de prendre le "risque d'erreur de la part de l'utilisateur" en compte sans déroger aux principes fondamentaux qui te permettront d'assurer la maintenabilité, l'évolutivité et la compréhensibilité de ton code : si l'utilisateur demande à modifier ce qui identifie clairement un ouvrage (son auteur et / ou son titre), hé bien, tu détruis correctement l'ouvrage "erroné", et tu le recrée avec les bonnes informations... Et le tour est joué.

Alors, tu me diras que, du point de vue des performances, c'est moyen moyen, et tu n'as absolument pas tord, mais, dis toi que, à partir du moment où il faut attendre une introduction de la part de l'utilisateur, les problèmes de performances passent en second plan. Et c'est d'autant plus vrai que, ici, le processus de destruction / reconstruction d'un ouvrage ne prendra que quelques milli secondes au maximum