Author: Alexander Kure
Date: 07:52:26 01/06/06
Go up one level in this thread
On January 06, 2006 at 10:09:30, Gerd Isenberg wrote: [..] >>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. Yes. > >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
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.