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.
---------------
Now Playing: {SYNTAX ERROR AT LINE 1210}
