Bonjour à toutes ! Bonjour à tous !    
 
Je viens de commencer la "programmation orientée objet" avec Java comme 1er langage POO. J'ai auparavant fais du C, du VB, et de l'ADA. J'avoue être assez déconcertée par l'approche objet mais apparament, cela est un réel plus.  
 
Alors voici ma question. En effet, je souhaite créer un "plateau de jeu" (tab de 8x8) sur lequel, il est possible de plaçer sur n'importe quelle case au choix, un pion d'une couleur au choix.  
 
Mon problème concerne la structure des classes et les méthodes s' y rapportant. J'ai lu dans un tutorial, qu'une classe objet devait définir tout ce qu'il était possible de faire avec le-dit objet. Donc, la méthode "Placer_pion_sur_plateau" devrait logiquement prendre place dans la classe Pion et non dans la classe Plateau. Ainsi, cette méthode prendrait en paramètre (un tableau, une abcisse, une ordonnée) et renverrait la modifications sur les variables d'instances (Private) du Pion (private abscisse et private ordonnée) et retournerait le plateau au Main avec la nouvelle valeur pour une case(i,j).  
 
Est-ce bien ainsi qu'il faille proçéder s'il vous plaît ?  J'ai tenté le codage des 2 classes mais la méthode ne passe pas. Vraiment, je souhaiterai juste savoir si mon découpage logique est le bon  
 
J'ai bien conscience que ma question peut paraître bête pour des professionnels mais vraiment, je souhaite avant tout comprendre à 100 % la logique du "orienté objet"    
Je le répète, il ne sagit pas d'interrogations concernant le codage en soit mais sur la compréhension des structures de données relatives à "l'orienté objet"    
 
Merci beaucoup pour toute l'aide que vous pourriez m'apportez  

Non, ta question n'est pas bête du tout.
 
Ce qu'on apprend à l'école ou dans la plupart des bouquins contient une belle part de supercherie. Oui, on appelle des méthodes sur des objets. Mais ça ne veut certainement pas dire que tous les comportements doivent être modélisés comme des méthodes de l'objet auquels ils se rapportent !
 
On en avait discuté un jour ici, je crois avec nraynaud, et je vais essayer de te résumer ça du mieux que je peux. J'espère ne pas dire de sotises, mais de toute façon, je suis certain que ça vaudra mieux que les bobards qu'on lit dans la plupart des tutos et bouquins.
 
A l'extrême, dans la plupart des applications "business", on ne voit pratiquement que des méthodes "exogènes". Tu as modélisé des clients, des factures, des cartes de crédit, des comptes bancaires, des transactions, etc. Mais souvent, aucun des objets mentionnés ne contient de méthode. On passe par d'autres classes, qu'on baptise "managers". CustomerManager, TransactionManager, ... Ces classes contiennent les méthodes qui te font que qq chose se passe : addCustomer, completeTransaction.
 
Tu modèlises un comportement d'un objet sur cet objet quand ce comportement lui est intrisèque. Par exemple, on pourrait imaginer qu'un pion possède les méthodes suivantes :
 
- changeColor (Color color);
- changeAspect (Aspect aspect);
- Position getPosition (); [et encore; c'est discutable]
 
Pq ne retrouverait-on pas un "movePawn" ici ? Parce que ce faisant, ton pion deviendrait un anarchiste complet : qui te dit que la case de destination n'est pas occupée ? Qui te dit que le mouvement est légal ? Pas plus que ce ne sont les pions sur ton tableau qui décident du bon respect des règles du jeu dans la vraie vie, il n'y a aucune raison de laisser ce privilège de décision à un bête pion orienté objet. Ca deviendrait bordelique : un pion qui commencerait à bouger, à notifier le plateau de jeu qu'il est en train de bouger, à contrôler la légalité du mouvement, à adapter les scores et à dire à qui le tour de jouer. Super bordelique.
 
Tout ce qui requiert une action extérieure ne constituera pas une méthode de ton pion, mais plutôt une méthode d'un "manager" extérieur:
 
- movePawn (Board board, Pawn pawn, Position position);
- addPawn (Board board, Pawn pawn, Position position);
 
Au final, on retrouvera peut-être un grand chef d'orchestre pour coordoner le tout. Lui connaîtra les joueurs, le plateau, les pions, les mouvement exécutés depuis le début de la partie, les score.
 
Le plateau se contentera de connaître les pions et leur position. Les pions ne feront rien grand chose. Peut-être même ne connaîtront-ils même pas leur position.
 
Voilà, j'espère que cet exemple pratiquer t'apportera qq chose !
 
Attention : je n'ai fait que tirer les grandes lignes d'un pattern possible. Il n'exite pas, en O.O., de solution unique. Il n'y a que des modélisations adéquates ou moins adéquates. Ce qui est bon manitenant ne le sera peut-être pas si le contexte évolue. Mais parfois, on essaye de prévoir. Tout est affaire de compromis aussi : il est souvement inutile de s'embarquer dans de l'"over-design" qui ne servira peut-être à rien et qui alourdira inutilement le modélisation. Souvent, on prévoit un tas de possibilités d'extentions, mais ce ne sont au final pas les bonnes.

Une méthode, c'est un message.
 
Appeler une méthode d'un objet, c'est envoyer un message au dit objet.
 
Quand tu places un pion sur un plateau, trouves tu plus logique de dire au pion que tu le places sur un plateau ou au plateau que tu lui ajoutes un pion? Et si c'est la solution deux, comment le plateau est-il mis au courant qu'il a un pion de plus?
 
À la base, un plateau est un conteneur de pions, il est donc relativement logique (imo) d' "ajouter un pion au plateau", donc Plateau.add(Pion).
 
À part ça, je suis d'accord avec Sircam: il est rare qu'il existe une solution unique en POO (par contre on a souvent des solutions "logiques", parfois appelées "naïves" quand elles sont loin d'être idéales). Tant que tu peux expliquer (et défendre)  logiquement le raisonnement qui t'a ammené à ton modèle, il n'a aucune raison d'être invalide per se.

J'ai attentivement lu vos explications et illustrations sircam et masklinn     .
Je tiens à vous remercier énormément pour toute votre aide et votre patience. La façon dont vous présentez les choses est bien plus parlante et constructive que tout ce que j'avais pu lire jusqu'à présent. Je pense avoir maintenant cerné la logique "orienté objet" et cela grâce à vous   .  
Je m'en vais de ce pas mettre en pratique toutes ces précieuses informations  !    
 
Merci infiniement !