Author: Russell Reagan
Date: 15:29:02 10/23/03
Go up one level in this thread
On October 23, 2003 at 17:39:59, Dan Andersson wrote: > I believe you are mostly correct. But one thing that has been bugging me when >considering OOP and search is that I haven't yet found a class structure that >feels 'natural'. Various designs lack in orthoganality, decoupling, etc... > >MvH Dan Andersson It's funny you mention search in that way. I've been tinkering with the approach Bjarne mentioned in the interview since you posted it originally, and everything seems to be pretty straight forward until I get to the search. Maybe this is the same problem you are talking about. Things basically build on one another. I have (from memory) Color, Square, PieceType, Piece, BoardElement, Board, Move, CastlingRights, Position, and Game. Up to this point, the naming is the thing that has given me the biggest problem. IE you could swap the names of Square and BoardElement and it would still make sense. At the moment, Square is a board index, while BoardElement would know if it has a piece on it or not. I've thought about having a BoardIndex and a Square (instead of Square and BoardElement, respectively), where the Square knows what piece is on it. I guess if naming is the biggest problem, that's not too bad (or maybe it's an indication of a poor design). At this point, I could either write a search function that is passed a game, or have something like a Search object, or SearchAlgorithm object, that takes a game in its constructor. Both approaches seem to have about equal merit. The basic function seems most natural at first, but a class would make SMP search easier I think (you could basically create two instances and have them share some static data). Maybe after I've created the Game class, I'm done with the creation of new types, because now I have a way to move around the game tree. The rest is just algorithms (until you want to add a hash table or something, but that's an add on). I agree that it's hard to find a good design that feels natural. There is always something a little awkward. In my case, I think I may be taking too broad of an approach. For instance, I don't need all of those classes I mentioned above, depending upon what kind of program I make. Bitboards don't need a BoardElement so much, or a Piece really (just an array of PieceType). That would solve some of my naming conflicts. Writing stand alone classes, as Bjarne mentioned, has seemed to make it easier though.
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.