Author: Matt Taylor
Date: 21:57:37 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. Sort've. Functions with side-effects and more complex functions can keep things efficient. Also, inline functions can help, too. >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. I agree in part, but I think OOP is aimed more at applications programming. I am a systems programmer, and I have seen very little object-oriented systems code. There are always a number of constraints on systems code, and since it is necessary to take them into account, OOP is generally not regarded as an option. i.e. I can't have an interrupt handler as part of an object because an interrupt routine is not called like an object's member function. >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." You can afford the luxury of OOP in many areas while keeping major hotspots fast. Also, OOP is not -necessarily- slow. Some abstractions (virtual functions) are slow, but even then somebody could build a chip that made them fast. Other abstractions (inheritance) are free. >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. Java does. Integer is immutable, though. >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! :) Color wouldn't make any sense as you don't perform operations on color (well, except test/compare). A bitboard object could be useful, actually. You can write a function that returns any bit, a function that returns the MSB, and a function that returns the LSB. Also, you are then free to use any bitboard representation and change as you wish. Inline functions can preserve the efficiency of your bitboard. I think OOP is often confused with data hiding. Data hiding is important to eliminate coupling and promote cohesion. OOP is a way of grouping your code which often goes intertwine with data hiding. They coexist nicely, but either can be employed without the other. -Matt
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.