Design Chess - Object Oriented Design

Question

I am trying to design online chess game(figuring out required classes). Need some suggestion on choosing better option to validate the move. So, lets say, I have below class

Option 1 : My Initial thought process was to have a validator Factory defined, and set of validators specific to each piece.

Public class Game{
 private String id;
 private Player player1;
 private Player player2;
 private GameStatus status;
 private Board board;
 private Color currentTurn ; //who have to make move now?
 private static Map<PieceType , List<IValidate>> validators; 
 static {
 validators = initialize_the_appropriate_validators
 }
 public boolean makeMove(Move move){
 PieceType type = move.getPiece().getType() ;
 for(Ivalidate validator : validators.get(type)){
 if(!validator.validate())
 throw new InvalidMoveException("Move not allowed!");
 }
 .............
 }
}
 public class KnightMovesValidator implements Ivalidate{
 public boolean validate(Move){
 //TODO: vlidate if it is proper move based on the piece
 }
 }
public class Box{
 private int x ;
 private int y ;
 private Piece piece;
}
public Board{
 private Box [][] boxes;
}
public class Move{
 private Box src;
 private Box dest;
 private Piece piece;
 private Player player;
}
 public enum PieceType{
 KINGHT , ROOK , KING , QUEEN .......
 }
 public enum color{
 BLACK,WHITE
 }
 public class Piece{
 private PieceType type;
 private Color color;
 private boolean isKilled;
 }

---

Option 2 : When I searched on the internet to validate my implementation. I found the below design in many places.

 Public Knight extends Piece{
 public boolean canMove(Box src , Box dest) {
 //TODO : implement 
 }
 }

The idea is, instead of having external validator. Each piece is saying whether the requested move is possible or not. It sounds better than my design to me. But still I have some question here... Box is aware of the class Piece because it is holding it.
Should Piece be aware of Box(its location) ?? Shouldn't piece be independent of Box?

Is this correct way of designing our POJO? What is the thought process behind it? Please throw me some light.

Thanks.

• Steve: This design strikes me as faulty. Games don't move pieces - players do. And pieces don't determine their own valid moves either - I'd be tempted to think probably that functionality belongs at the game level, considering the overall arrangement of pieces. Also colours don't have turns - players do.
• Ben Cottrell: The goal of Object-Orientation is to avert an explosion of complexity in modelling behaviour of your program. The complexity of chess, as in most games, lies within the rules of the game rather than the physical entities. Indeed, the physical entities in Chess are inanimate objects which don't actually do anything themselves - you can represent them trivially as plain data structures - so it stands to reason that there's no point using object-oriented constructs to represent Pieces or a Board. Worthwhile reading: chessprogramming.org/Main_Page
• Flater: @Steve: But a game is effectively a list of moves (with some additional information), so it's a semantical argument, not an architectural one. AddMove would be perfectly fine in the Game class, and validating that move isn't wrong either as a last line of defense against bad input.
• Steve: @candied_orange, but pieces don't follow rules, players do. A piece may be a good place to store the movement pattern of each piece, but whether any piece can be moved is a function of the state of the whole system, including in some complex cases its history (such as the castling rule, which involves a transactional move of two pieces, provided they have not previously moved). This neatly illustrates not only that OO modelling often considerably more complex than alternatives, but so too that even experienced practitioners often arrive at results which are unreal.
• GHP: The validity of a move requires the intersection of the rules for each piece for their possible moments, but also the involvement of the board/game models because they would understand which spaces are empty, or not off the grid, or if moving a king into a space will trigger the king to be in check (not allowed, I believe). Therefor I would not start with the Validation method attached to the Piece, since much more validation for a move happens at the board/game level.

Answer 1

If you want to really practice object-orientation here is a completely easy rule to follow:

Don't have getters!

This will force your design to assign real responsibilities to things, you will almost certainly automatically follow the Law of Demeter, Tell don't ask, and other important principles of object-orientation.

Don't let people tell you that things can't have behavior because they are inanimate. In object-orientation all things live. Every object has behavior, privacy and does its own things. It is desirable to anthropomorphize things in object-orientation.

Your design at this point is very far from this, so you'll have quite a bit of work to do, but if you manage to pull it off without cheating (there are ways to cheat this rule :), you'll have an experience with object-orientation that quite frankly not a lot of people have.

• user949300: At some point you may make an exception to add a few getters, but this is excellent advice.
• Jeevi: Thanks for your very useful suggestion. Reading about this Law of Demeter now (in clean code book). Any recommendations on Good book or blogs for Object-Oriented Design?
• Robert Bräutigam: I have issues with all books that I've read so far. Clean Code is certainly not the best book, when it comes to OO. Uncle Bob Martin is sort-of a mixed-paradigm guy with strong tendencies toward the procedural. Best book for me so far is Object Thinking by David West. It has great historical perspectives, conveys how to think in objects. It is tedious at times, but worth a read. As for blogs, let me plug my own blog The New Java Developer