Author: Russell Reagan
Date: 22:30:33 07/01/02
One problem I often have when attempting to approach a problem from an OOP perspective is that I find it hard to determine which things belong to the object and which things don't. For example, in a chess program, I would think that the "make move" function and "generate moves" function would belong to the "position" object, since the only data that is being operated upon is the position's data. But what about the search algorithm? That really only operates upon the position object as well, but it doesn't seem (to me) like it belongs in the position object. So an AlphaBeta() function and Evaluate() function would seem to not be part of the position, even though they only use the position's data. One thought I had was to think of it like the STL is setup. There are data structures, which don't do a whole lot by themselves. They simply act as containers for your data (eg. vector, list, etc.). Then there are the STL algorithms that are seperate from the objects, but act upon their data. From this point of view, the position would seem to be seperate from the alpha beta and evaluate functions, and those would fall under the "algorithms" category. Then again, the STL has generic algorithms that will operate upon vectors, lists, maps, or whatever. Alpha beta might be a function one could write generically and apply to a chess position as well as a checkers position, but evaluate is certainly not. To further complicate the STL example, there is the generic sort algorithm that will work on a vector or a list. Then list goes and complicates things because it has it's own sort method. Go figure. So where do you draw the line and how do you decide what goes where when developing in an object oriented manner? Russell
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.