Author: Tony Werten
Date: 22:59:53 01/06/06
Go up one level in this thread
On January 06, 2006 at 14:52:52, Gerd Isenberg wrote: >On January 06, 2006 at 13:41:06, Tony Werten wrote: > >>On January 06, 2006 at 11:54:27, Gerd Isenberg wrote: >> >>>>>But doesn't hiding the implementation for this scalar wrapper class - without >>>>>any virtuals - also imply that it don't cares whether a public interface is used >>>>>internally but also privat members? >>>> >>>>Sorry Gerd, I don't quite understand your question. >>>>Can you try to rephrase it? >>>> >>>>Best, >>>>Alex >>> >>>If isAdjacent is a const member or friend, it has read access to >>>private/proteceted members - but is not forced to do so - it may also use the >>>public interface only. If so, should that be a reason to make the function not >>>member or friend? >>> >>>Making a function a member of a class or not - should imho not only depend on >>>its access rights, but also on the semantic and logical relations of the >>>function. >>> >>>I mean with some point and rectangle classes - i found it so far somehow natural >>>or at least familiar to have the boolean isPointInRect as member of a rectangle. >> >>Hmm, it seems I have different thoughts. I agree with the above. isPointInRect >>could be a member of CRectangle, but not of CPoint. >> >>By the same reasoning, a CSquare should not have an IsAdjacent, but a CBoard >>(containing CSquares) should. > >Now it becomes interesting ;-) > >Assuming CSquare already "knows" how to move on the board as suggested by Alex, >why should a container of squares be exclusive owner of the isAdjacent property? Because it's the CBoard that decides wether 2 squares are adjacent, not the squares itself. When you design a new board (ie round or something), the squares stay the same, you just override IsAdjacent and other stuff (goUp,goDown etc) in CBoard. I disagree with having a square know how to move. Squares don't move. Squares can have pieces on them that know how to move. When playing a chessvariant with new pieces, just derive the new piece from CPiece and override its moving. > >CBoard might also contain no CSquares at all, but bitboards!? Implementation details :) Every board contains squares. It also might use some internal representation for it that is different. Disagreement again btw. Bitboards should be implemented in the representaion of the pieces, not the squares. IMO Wether this all can be done efficient might be something completely different. > >What i know for sure - my previous (still working) design decision, to derivate >CSearchTree from CNode to implicitly get a root-node for the search was a very >bad idea (don't derivate from concrete classes!). Deriving seems a but too much. Why not let CSearchTree just contain CNodes (or CBoards/CPositions) fe a startpointNode and a currentPositionNode. Tony > >Cheers, >Gerd
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.