Appeler des méthodes qui renvoient des objets

Bonsoir,
Après avoir fait 2 ans de C, je commence une initiation à la POO, pour cela on nous propose des TP à faire en C++, dont on nous a donné quelques connaissances rudimentaires.
En fait je dois coder un mastermind. Dans l'énoncé, on nous a proposé une ébauche du diagramme de classe :
http://img440.imageshack.us/img440/7702/mastermind.png

Mais en fait c'est la première fois que je vois ça, et je n'en ai pas vraiment entendu parler dans les tutoriels que j'ai lu, ces prototypes là :
Correction corrigerCoup(), Coup jouer(),
Ce sont des méthodes qui renvoient un objet de classe Correction, Coup ? ça me semble bizarre.
Si c'est ça, je ne comprends pas le "principe" de la chose ? Quel intérêt ?
Il ne faut pas plutôt avoir dans "partie" des objets attributs de classe "correction" et comme ça on crée une méthode dans "partie" qui utilisera une méthode de la classe "correction" ?
Voilà donc je voudrais savoir à quoi ça peut bien servir, car j'ai remarqué qu'il n'y avait pas d'erreur de compilation.
C'est dur la POO quand on s'y met, je m'y attendais mais c'est un choc...
Merci à vous !

Bonsoir,

qu'est-ce qui vous tracasse en fait ?
pourquoi rendre une instance de la classe Correction (à moins que Correction ne soit une énumération) serait plus bizarre que de rendre un entier par exemple ?
en C vous n'avez jamais écrit une fonction retournant une structure par exemple ?

Salut,
int tab[] devrait plutôt être std::vector<int>.
Sinon, pour répondre à ta question, oui les fonctions retournent un objet. Pourquoi ? Ben, je sais pas. C'est peut être cohérent avec le design ou pas. Il n'y a pas assez d'éléments ici pour répondre si c'est pertinent ou si la classe Partie ou Joueur devrait avoir une fonction plus spécifique.

Merci pour vos réponses !
Eh bien oui, j'ai déjà renvoyé des structures, mais là je ne comprends pas le principe. Quand je renvoyais une structure c'était pour avoir un champ de donné rempli. Mais là avec ce que j'ai appris en C++, même si je sais que les attributs sont des données; je ne comprends pas la démarche. Est-ce courant de faire ça ?
Si par exemple je déclare des objets : Partie partie; et Correction correc;
Puis si je fais correc = partie.corrigerCoup();
Qu'est ce que cela peut bien apporter ?
De ce que je comprends, l'intérêt de faire ça, par analogie avec les structures, serait d'avoir peut être de nouvelles valeurs d'attributs, mais en quoi ça me permettrais de corriger (en gros il faudrait vérifier les pions joués par l'utilisateur par rapport à la combinaison cachée, et lui donner des indications de corrections).
Donc je vois mal pourquoi on fait ça ?
Bonne soirée.

Salut,

Avant d'apporter ma pierre à l'édifice pour résoudre ton problème, je voudrais te reprendre sur le terme "méthode".

On préfère généralement parler de "fonction membre (d'une classe)" plutôt que de méthode, car, bien que le terme existe, il implique qu'il s'agit d'une fonction membre particulière en cela qu'elle est virtuelle, et donc que son comportement peut être modifié, dans le cadre d'un héritage public en vue de profiter du polymorphisme, dans les classes dérivées.

Ce n'est qu'un détail, mais je voulais attirer ton attention sur ce point ;)

Ceci étant dit:

Je me pose la question de savoir dans quelle mesure celui qui a créé ce diagramme de classe ne s'est pas pas "simplement" trompé dans le terme qu'il a utilisé pour indiquer le type de retour de la fonction jouer, dans le sens où il aurait voulu utilisrer une... solution :P (après tout, lorsque le joueur... joue, il propose une solution, non :question:)

Quoi qu'il en soit, le schéma d'exécution "classique" d'une partie de mastermind sera (une fois que l'on dispose d'une partie et d'un joueur) proche de
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 trouvé passe à faux définir la solution à trouver tant que (pas trouvé et nombre de coups plus petit que nombre de coup max ) permettre au joueur de faire sa proposition comparer la proposition du joueur avec la solution à trouver (cela revient à obtenir la correction) si (correction donne "tout bon") trouvé passe à vrai sinon afficher nombre de bonnes couleurs bien placées afficher nombre de bonnes couleurs mal placées afficher nombre de mauvaises couleurs fin si fin tant
Autrement dit, la fonction jouer de ta classe joueur va... se charger de créer une représentation de coup (ou de solution) en fonction de l'inspiration (des déductions) du joueur.

Or, il faudra... récupérer cette représentation de coup (ou de solution) afin que la partie soit en mesure... de la comparer avec la solution à trouver.

(Au passage, cela implique qu'il faudra passer le coup proposé par le joueur à la fonction corrigerCoup de partie ;))

Lorsque l'on appellera la fonction corrigerCoup, nous allons demander à l'objet de type partie de nous indiquer:

le nombre de bonnes couleurs bien placées
le nombre de bonnes couleurs mal placées
le nombre de mauvaise couleurs
parce que ce sont ces nombres qui permettront au joueur d'essayer de déduire ce qui a le plus de chances de correspondre à la solution à trouver au prochain coup;)

Le tout, sans oublier le fait que, si le nombre de bonnes couleurs bien placées correspond au nombre de couleur à chercher, cela signifie que la solution est trouvée ;)

Mais cela implique qu'il faudra bien récupérer ces différentes informations afin de pouvoir déterminer si le joueur a trouvé la bonne solution ou non (car, en vertu de la responsabilité unique, ce n'est pas à ta classe partie de se charger de cet aspect du problème ;))

Bref, comme tu peux le remarquer, chaque type (ici joueur, partie et solution) a sa propre responsabilité, mais il est important de disposer d'information "créées" (ou en tout cas mises à jour) par certains objets pour être en mesure... de les faire vérifier par d'autres.

Citation:

De ce que je comprends, l'intérêt de faire ça, par analogie avec les structures, serait d'avoir peut être de nouvelles valeurs d'attributs, mais en quoi ça me permettrais de corriger (en gros il faudrait vérifier les pions joués par l'utilisateur par rapport à la combinaison cachée, et lui donner des indications de corrections).

D'une part parce que, bien souvent, le comportement d'un objet (la manière dont il rend le service que l'on attend de lui) est fortement lié aux... données dont il est composé;

D'autre part, parce que la seule différence entre une structure utilisée en programmation séquentielle et un objet utilisé en POO (du moins, dans le cadre de ta question), c'est que, pour les premières, tu te serais basé sur les données agrégées par ta structure, alors que, pour les seconds, tu te basera sur les services que tu es en droit d'attendre de la part de l'objet.

Autrement, qu'il s'agisse d'accéder aux données dont une structure est composée ou aux services que tu es en droit d'attendre d'un objet, il n'y a rien à faire: pour y arriver, il faut... disposer d'un instance de la structure ou de l'objet...

Et le meilleur moyen d'y arriver est encore... de faire en sorte qu'une fonction renvoie une instance de cet objet ou de cette structure ;)

Au final, la seule différence réelle qu'il y aura entre une structure "procédurale" et un objet sera que l'interface publique (les fonctions membres auxquelles tu peux accéder "de l'extérieur") de l'objet peut rester beaucoup plus stable et indépendante que la manière dont les données sont organisées dans une structure:

Si, pour une raison qui ne peut être que bonne, tu décide de modifier la manière dont les différentes données sont organisées dans une structure ( par exemple, remplacer un simple tableau dynamique par une liste simplement chainée), tu devra vérifier et (sans doute) modifier une très grosse partie du code de tout le projet: chaque endroit du code où la structure est utilisé est susceptible de devoir être modifé.

Par contre, en orienté objet, si tu prend la même décision, les seules parties du code qu'il te faudra revoir et, éventuellement, modifier seront... la manière dont les différentes fonctions membre de l'objet modifié réagiront.

Tant que tu gardera la même interface publique, avec des fonctions membres de même nom et présentant la même signature, tu sera en mesure de modifier la manière dont n'importe quelle donnée est représentée en mémoire sans jamais devoir aller vérifier "dans le reste du code" si, par hasard, il ne faut pas modifier l'une ou l'autre ligne de code.

Ce principe s'appelle "l'encapsulation", et, même s'il est possible de le mettre en œuvre en programmation procédurale pure (c'est le cas de la structure FILE, par exemple), il faut avouer que c'est très largement plus facile d'y arriver avec la POO, parce que c'est un des fondements même de cette technique de programmation ;)