Your design is fairly different from many other chess program designs. It is somehow unique that way, which is a good thing.Henk wrote:Yes as I said the code is not written for others. By the way If I look at code from other people I'm shocked too.
Also I get the impression that your design is consistent to a certain degree. It looks unusual for the eyes of most of us but at least I would say that it is a *possible* design. If I would be asked to create a really pure OO design of chess board, squares and pieces I would do it in a completely different way but it would still be necessary to have some concept for linking squares to pieces, which you do with the Location reference in the Piece object. That is not so bad.
I tend to like your "Location.BitCoord" concept. It corresponds to "1ULL << sqr" for a given square number 'sqr' from 0..63.
Nevertheless I believe that your program is overdesigned. I think that a lot of your code is actually not needed for a working board representation, even with OO. It would be sufficient to only have a (somewhat larger) Position class with low-level operations like
PutPieceOnBoard(Location location, PieceType pieceType)
RemovePieceFromBoard(Location location)
MovePiece(Location from, Location to)
PromotePiece(Location location, PieceType promotionPieceType)
UnpromotePiece(Location location)
and high-level operations like
MakeMove(Move move)
UnmakeMove(Move move)
that are based upon the first ones. It would drastically reduce the complexity of your program, and it would put the code where it belongs. Your current methods Piece::PutOnBoard() and Piece::RemoveFromBoard() actually do not operate only on pieces but they modify the Board as well, so that should be part of methods of class Board resp. class Position.
Things can be done differently, of course, and again: I don't say the design is "wrong". I just say, it will most probably be a dead end, it will not help you to reach higher search depths due to inefficiency.
It is just a proposal, maybe you want to think about it.
Sven