Author: Gordon Rattray
Date: 03:26:25 07/02/02
Go up one level in this thread
Russell, With design there's no right or wrong answers, just good and bad ones. I think a good start is determine what are the main criteria you want to aim for in a design. Do you want to aim for the most simplistic and understandable design? Easiest to change? Or maybe performance is your main objective? Sometimes you can have it all, but at other times you will have to make tradeoffs. Putting the "make move" and "generate moves" functionality within your "position" class sounds reasonable to me. However, should a position be able to evaluate itself? In terms of simplicity, I'd say no - it should be done by another class. But for performance, you may find that the evaluation function needs to work closely with the internals of the position implementation (e.g. bit boards). I think the search functionality should almost certainly be done outwith the position class. The search should be done in a "chess position analyser" sort of class. This class is passed a position object and it returns a "best" move. To me, it just isn't intuitive to expect a position object to be able to search itself. Remember also that software development is an iterative process. While you have to aim to get the design right first time, chances are that you won't. As long as you start with a reasonable design, you should be able to move some things around once you start coding. Then you can more concretely assess what's hard to understand or unperformant and use this as the basis for some rework, e.g. moving the evaluation functionality from one class to another. Gordon On July 02, 2002 at 01:30:33, Russell Reagan wrote: >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 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.