Author: Mridul Muralidharan
Date: 08:18:37 01/06/06
Go up one level in this thread
Hi Alex, Just a comment about IsAdjacent() below. Thanks, Mridul On January 06, 2006 at 08:44:09, Alexander Kure wrote: >On January 06, 2006 at 03:37:17, Gerd Isenberg wrote: > > >[..] > >>>3) Instead of low-levely maipulating a square by means of operator+=() you could >>>declare the following high-level functions in class CSquare: >>> >>> void Up(); >>> void Down(); >>> void Left(); >>> void Right(); >>> void Next(); >>> void Previous(); > >> >>Isn't it better to return a reference for this functions, to cascade several >>directions in one expression? > >If you like to cacsacde these functions then your suggestion of returning a >reference for these functions is the way to do it. > >> What about throwing an out of board exception? > >Good idea but depends on how these functions should behave. You could for >example let them wrap around the board. > >>>4) You could also declare other convenient functions outside of class CSquare: >>> >>> bool IsAdjacent(const CSquare&, const CSquare&); >> >>while polymorphism is a nice thing to have, this function may also be member of >>CSquare. > >I don't understand what polymorphism has to do with it but concerning your >question if this function may also be member of CSquare: > >From the perspective of encapsulation - an important issue in OO - it is better >to define IsAdjacent() as a non-member non-friend function in order to increase >encapsulation. >The idea is to separate the implementation issues of IsAdjacent() from the >internals (read: non-public interface, i.e. protected and private interface) of >CSquare by just using its public interface only - thus increasing encapsulation. >If this can be done without a serious performance penalty this is surely the way >to do it. >Since IsAdjacent() can be implemented by using CSquare::GetFile() and >CSquare::GetRank() that are both inlined member functions there is no >performance penalty at all. >A change of the internals of CSquare later in the development process does not >effect (read: need to be changed) non-member functions like IsAdjacent() that >rely on the public interface of CSquare only. In contrast all member functions >of CSquare dependant on the internals are effected and need to be changed. > >Best, >Alex Just wondering about the design decision here ... I am not really sure if IsAdjacent() should be external to CSquare. It just so happens that , in this case , we can deduce the fact that one square is adjascent to another by looking at the public interface. IsAdjacent() would be similar to isEqual() ... something which the object has to decide upon , not an external function. Example, a 0x88 CSquare , a 8x8 CSquare and a 12x12 CSquare would have different ways of finding out who is adjescent to whom , etc ... if all of them extend from CSquare - this can be simply handled by making IsAdjacent() a virtual method of CSquare itself. Ofcourse , I could be misunderstanding the problem here. Thanks ! Mridul
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.