Author: Gerd Isenberg
Date: 11:52:52 01/06/06
Go up one level in this thread
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? CBoard might also contain no CSquares at all, but bitboards!? 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!). 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.