Author: Matthew Hull
Date: 20:18:53 02/13/03
Go up one level in this thread
On February 13, 2003 at 22:23:45, Russell Reagan wrote: >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! :) I think your respondent makes the crucial point. OOP is for making re-usable objects that can be widely used and reused by more than just one application. The point is to ultimately reduce programming labor costs both for development and mantainance. But a chess program is more like a custom built, high speed, low drag, top-fuel dragster, hand crafted for optimum performance. OOP is for building off-the-shelf components that can build more than just one thing saving time and money in the long run. At least that's the way I understand it. Then again, some people are so comfortable programming OOP that it's the only way they would ever code a chess program (or any other program for that matter). Regards, Matt
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.