Author: Russell Reagan
Date: 19:23:45 02/13/03
The background... One of the problems I have had with writing object oriented programs is deciding where to draw the lines between what goes with what object, what should even be an object in the first place, and so on. In an online discussion, I was describing some of the various standard board representations such as 0x88 and bitboards, and asking how you could make use of these in an object oriented program. The problem I'm struggling with is, if you have modular objects, then each object won't know how other objects work. This leads to problems when you create a "board" object and a "move" object. The move object shouldn't know what board representation you are using, which could lead to a less than optimal program from a performance standpoint. For instance, it's difficult to take advantage of bitboards if the rest of the program doesn't know you're using them. The response... One poster gave an opinion I found to be very interesting. He writes: "Generally, in OOP, you should be thinking about the objects - ie. the pieces, the board, the player, a given position, and not the representation at all. Basically you're gonna have a list of board squares with references to piece objects, or a list of piece objects with a property specifying their position. While adequate for 99.9% of applications, this arrangement might make you cringe. OOP, while being applicable to pretty much every domain, is aimed more at systems-level programming where you're trying to represent real life concepts in code, and where therefore the representation is less important than the behaviour. The idea is that you start off making something that acts the way you want it to, and only later do you start worrying about optimal representations and so on. On the other hand, computer chess (as I'm sure you know) is a bit of an artificial problem as you're mainly concerned with algorithmic efficiency, and therefore it makes some sense to have slightly less clear code in the pursuit of optimisation. It's been studied long enough that making correct code (which is what OOP is about) is no longer as important an issue as making efficient code. Especially since the bottlenecks in computer chess are well researched and documented, hence all the 'standard' representations and so on." I found this opinion that OOP doesn't serve a great purpose in a domain such as computer chess to be quite interesting. It makes good sense to me, but is it valid? I'd be interested to know what computer chess people think about this. If it does serve a purpose in computer chess, then that raises more questions. One question I have pondered in the past is at what level do you draw the line for what should be an object and what should not? For instance, we do not create Integer32 objects for 32-bit integers, and re-implement all of the operators. That work is already done for us, and the default implementation is probably going to be superior to anything we re-implement. So what about something like bitboards? Most of the operations done on a bitboard (mostly bitwise operations) are already implemented for us. Do we re-create all of this work that has been done for us, and done well? Similar questions arise with other objects. A piece sounds like a good candidate for objectification. Do we create objects for 'piece type'? How about 'color'? Color could be re-used in the 'game' object as the side to move. Sounds good, but it sounds like creating a 'color' class might be more work than every place it is used. And besides, if you just have your side to move stored as an unsigned value, you can use it in arrays to lookup things quickly. So now I'd have a program that uses objects in some places, but not others, and now I feel like I have a bigger mess than if I had just written the whole thing in C and lived in pointer hell. Round and round I go...and this is the dilemma. Help! :)
This page took 0.01 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.