Author: Alexander Kure
Date: 10:08:20 01/06/06
Go up one level in this thread
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?
This depends. If there is a performance issue that can be solved by having
access to the internal data representation of a class you should make this
function a member of that class.
Compare this to map member function std::map::find() and the algorithm
std::find(). The first one has O(log(n)) logarithmic time by making use of the
internal binary tree representation in the map class while the algorithm takes
O(n) linear time for lookup.
On the other side if you can implement a function by using a classes public
interface only then make this function a non-member function. Thus you also
decrease the dependency of clients to the public interface of that class.
Clients don't have to recompile because you want to add a new convenient
function to your class. Encapsulation and decoupling!
>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.
No. It should depend on encapsulation and decoupling issues.
>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.
Good point. This function should not be part of the interface of the rectangle
class. IsPointInRect() is just a different concept. Making it part of the class
increases coupling of different concepts in one class.
Another point:
Consider the standard C++ complex class.
Only operator+=() is defined as member function, but operator+() is not.
Why is this so? Encapsulation! You can implement operator+() outside the complex
class by just using complex' member function operator+=()
complex operator(const complex& lhs, const complex& rhs)
{
complex temp = lhs;
temp += rhs; // calls temp.operator+=(rhs);
return(temp);
}
>May be my autodidactical oo-knowledge needs some lifting ;-)
I recommend reading Scott Meyers' excellent book "Effectiv C++", Addison Wesley,
3rd edition.
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.