Author: Rémi Coulom
Date: 06:40:36 07/02/02
Go up one level in this thread
If you want an example of OO programming applied to chess, you can take a look at my freeware C++ chess library: http://remi.coulom.free.fr/programs0046.tar.gz I do not claim it is example of good design (especially since it is a little "outdated" C++ style: no namespace, etc.), but it can give you some ideas. The STL is a nice example of good design, but keep in mind what it is about: a template library for generic container classes. A chess program does not need to be that generic. I think it is not necessary to make your code more reusable than what you need. Making a generic "Board" class that could be reused for a checker program would be possible, but there is no point in trying to make it that generic if you are not going to reuse your code for a checker program. There is often no definite answer to questions such as "should function F be a member of class C". The fact that it only operates on the data of this class is not enough to decide that it belongs to it. Often, functions that operate only on the data of a class should _not_ be member of it. By not being a member of the class, it become independent on its internal structure, which is good and can make your code even more reusable. Access to internal structure is a much more important criterion in deciding whether a function should be a member or not. The decision is sometimes an efficiency/maintainability tradeoff. About the evaluation function, I think it generally should not be a member of the position class. The reason is that there is no "absolute" evaluation function, and you may wish to have many different evaluation functions in your program. Also, an evaluation function often has its own data (path to tablebases, parameters, ...), which it would make no sense to add to the position data. About the move generator, I have also put it in separate class in my library. The reason is that it is designed to work in different passes (pseudo-legal move generation, then legal move generation), the second pass being optional. As a consequence, it has to maintain an internal state and must be in a separate class. If needed, I could use the "friend" keyword to let it access the internal structure of the position class. This kind of situation is also typical of iterators in container classes. Also, keep in mind that there is no absolute best design. It is often a matter of finding a compromise between genericity, simplicity and efficiency. I hope this advice helps and wish you good luck with your program. Rémi 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.