I'm having a small design issue with a Checkers game to be done in Java--
I'm not really worried about coding it, I can do that.
The problem is listing out the dependencies between classes.
For example, what should be responsible for what?
IF I code the program with the checkers pieces being capable of moving on the board, they need to know where they are on the board.
The problem with this? Should pieces really be responsible for knowing where they are on the board, or should they simply be 'used' as pieces?
The problem is broken down into two cases (and could be broken down into more, but for now let's say two cases).
The first case--
Piece base class, BlackPiece and RedPiece derived classes.
CheckersEngine emulates where the pieces can move within the board (adds movement restrictions, etc).
With this method, a piece (since it's really just "a piece") is only responsible for knowing if it has been attacked and killed. It does NOT hold responsibility for moving, since the piece is just "a piece."
The problem with this? I'm no forcing the board to determine when a piece moves and where.
I thought the design for that would be sloppy, and tedious. Sure it is the Engine's responsibility to make the game run, but I just felt that this design could be improved.
The second method results in pieces being more than pieces - they are now CheckersPieces. CheckersPieces know their direction of movement within a given CheckersBoard (so they must have a reference to the Engine).
I don't mind this pattern, because now within the actual Engine, upon loading I can simply call upon "move" for a piece and the piece will move with its given direction.
For some reason I feel a bit stuck. It feels as if the pieces now have too much responsibility?
Really, I just want to know if my approach is correct (and, just as a reminded, my approach is the second method).