Author: Gerd Isenberg
Date: 07:09:30 01/06/06
Go up one level in this thread
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. Wrapping is probably not what most like in chess. May be the square should become invalid. Most likely one should use a precondition before applying those functions. If i use a setwise representation of squares aka bitboards, i use some shift and wrap-ands to eg. get a set of all white pawn-attacks from left to right. So elements of target squares simply disappear if there is a h-pawn involved, since it don't attacks the a-file. > >>>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: Ok, polymorphism is not quite correct - having isAdjacent as member with implicite this-pointer and one reference as well as outside the class with two explicte references. > >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 I see - so you recommend to make functions none members if no private/protected access is needed, but only the public interface - which might be an pure abstract base- or superclass like an interface in java. 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? Thanks for the insights, 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.