I'm in a software engineering class and I want to practice some skills on the most basic case possible : tic tac toe. I know this is overkill but I want to do it in proper OOP.I designed a class diagram for it but there is one point where I don't clearly see what would be the best design decision.(Joueur means Player, PlancheDeJeu means Game board)Given this diagram, according to the Expert, Low coupling and Strong cohesion design patterns (sorry if those are not the correct english terms, I am translating) the score should be kept by the user class (Joueur). However, since there is no direct relation between Joueur and Systme I don't exactly know how the game could display the score in a clean way. In this diagram, Systme would have to ask the PlancheDeJeu object about the score and it would itself have to get it from Joueur. This seems wrong. I am trying to think of how to design an intermediary object that would link Joueur and Systme but I can't come up with a good idea.What would be the best way to go here ?Thanks !
Tic tac toe class diagram
design patterns;object oriented;game development
I would have modeled it this way:There are players as you modeled themA class Game has a state {scheduled, running, finished}, it also stores pointers to two players, and Game also stores the score for player 1 and player 2A System keeps track of all played/scheduled games (maybe it needs to provide a unique id for a new game, thus becoming a factory for games)If you want to compute e.g. an average score for a specific player, you can introduce references from Player to Game. For easier access, I wouldn't go the other way and traverse through the list of games to find those player X participated in.It's hard to analyse coupling and cohesion on such a small example, but I'd say that the score does not belong to a player, but to the game he participates in.BTW:In this diagram, Systme would have to ask the PlancheDeJeu object  about the score and it would itself have to get it from JoueurYour model says Joueur can access PlancheDeJeu, but not the other way.