Author: Bas Hamstra
Date: 05:11:30 11/06/97
Go up one level in this thread
Thanks for the comments. >Imagine an object called chessgame. >Chessgame could inherit from board, player, rule and piece or it could >have instances of board, player, rule and piece. Either way the >complexity is about the same whether we have a single object or an >object pudding. >[snip] I agree, but that is not my problem, at the moment. If I understand you well you say one can perfectly well work with one object, with functionality inherited from other objects or one object being a "cluster" of objects (several instances of smaller objects). Doesn't matter which method you use. I agree. But my problem is: WHICH objects?I have a few hundreds C routines and I now want to start in C++. Which routines to lump in which objects? Of course I could make one object CHESSAPP and dump all C routines there, make distinction between public and private functions and that's it. But I expected some more from OOP. For example: - I would like to reuse the internal board stuff in another chess app (later) - Idem ditto for the graphics basics - At some point I would like to stick another move generator in etcetera. So my thoughts were to make objects for all parts that possibly can be reused or might be replaced, including a movegenerator object and eval object. C++ was to make that sort of things easier, I believed. But alas, objects have to be things, can be no collections of routines. So where do I leave the movegeneration routines? Or the search? All in the board object? Then it is going to be an object with a huge number of memberfunctions. I don't like that. To replace the movegenerator would not be so easy. If I wanted to use the board stuff later in another program, I could inherit, but then I get a lot of unnecessary data too (including some not so small arrays). Regards, Bas Hamstra.
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.