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.

enter image description here

("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 Système I don't exactly know how the game could display the score in a clean way. In this diagram, Système 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 Système but I can't come up with a good idea.

What would be the best way to go here ?

Thanks !

  • What's your reason for Joueur having PlancheDeJeu and not vice versa? – McMannus Jun 7 '13 at 7:10
  • 1
    Over-engineering habits, here we come :) (I'm kidding, reducing to small examples for learning is good, as long as you don't obsess over what you've learned from them later for real projects.) – haylem Jun 7 '13 at 14:42

I would have modeled it this way:

  • There are players as you modeled them
  • A 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 2
  • A 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.


In this diagram, Système would have to ask the PlancheDeJeu object about the score and it would itself have to get it from Joueur

Your model says Joueur can access PlancheDeJeu, but not the other way.


Score is derived data from the accumulation of game outcomes. The result of the game should be stored on the "Game Board" object. From there you could take a couple approaches.

1) You could keep a set of all games played in the "System" and provide a public method "score(Player)" which would calculate the score for all games that "Player" has completed. This option seems like it fits the needs of your system in order to display the data.


2) The Player keeps track of all games they have completed and can respond to "score" appropriately.

It looks like you may be missing a class though.

Player - A participant in a Tic Tac Toe game Game (Board) - A stateful object that receives player input (moves) and determines win/lose/draw System - Displays data to a User(?), Instantiates new Games(?), Creates new Players(?).

System feels pretty nebulous to me. It seems like there should be a Controller of some sort which can start new games and keep reference to them for analysis of the outcome. Introducing this object would give the System the ability to focus on Displaying data rather than having the mixed responsibility of keeping track of players, games and whatever else to display the data requested.

Using the Controller, it would provide the method score(Player).

  • I'd say "controller" and "System" are synonymous, conceptually. – radarbob Jun 8 '13 at 4:16
  • Maybe. It is hard to tell what responsibilities "System" has in the diagram. It looks like a "catch-all" for whatever responsibilities are left over. – Seth M. Jun 10 '13 at 14:20

First one should clarify what is meant by score. If that means "the number of wins, losses and remis outcomes in all previous games", then it should be clear that the score cannot belong to a game board, because the lifetime of a gameboard should be just one game. So the score is a personal property of each player, meaning it is correctly placed there.

This picture gets even clearer if you think of having more than two players, all of them having a Tic Tac Toe tournament. And indeed, since you have to manage the existing players somewhere (independently from the game board), I guess you should add the players to the system in form of a relationship.

I am trying to think of how to design an intermediary object that would link Joueur and Système

Why not just creating a 1:n association between System and Player? That should be sufficient. There must be a place in the program where players and the empty game board will be created, a place where the actual two players are picked (among all players), and a place where they get the current game board assigned. These are tasks typically done by a different ("higher level") object, maybe the "System" object in your model.


I see no reason why the player themselves have to keep score of the game- in fact I think that the game board itself should keep score, otherwise which player keeps score? The human, or the computer? Do they both keep their own score? If so, that's duplication of data, which is never good, because you could end up with a case where those scores don't match and then you've got to figure out which one is right. I would keep the score on the actual game board, which then both the players and the system have access to!

If you really have some sort of objection with keeping the score on the board, you might have to create another class for storing data, which is very common in programs, which then all parties would have access to in a semi-static fashion, either through a singleton, or some sort of thread safe accessor/setter

  • 3
    The score for Tic Tac Toe on an actual game board? What should that be? I guess the score means here the number of outcomes of all previous games, which has a different lifetime than the current board. – Doc Brown Jun 7 '13 at 11:11
  • Thats a good point @Doc Brown, maybe then there is a game manager that would create game instances, tell the players and system about the new game instance, and then keep score on its own – Ampt Jun 7 '13 at 13:16

First off i don't think it is an overkill. To me it is a good way to visualise how you should start coding in an object oriented way. And you are getting there. Yay!

I am not an expert at this but this is how i would do it:

main for the flow of the game.

board for the logic for all the tic tac toe moves.

gameController to control the game. in this case which player's turn it is.

input to get the player's move

output to print out all relevant info including the board.

you might end up with some very short files but it is okie. you will need them when you move on to bigger games. :)

hope this helps.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.