On 23 Feb 2004 22:52:49 -0800,
spam_bait101@yahoo.com (sb) wrote:[color=blue]
>
>I'm sure some people feel very productive when they write
>
>private:
> t m_foo;
>public:
> const t& foo() const { return m_foo; }
> t& foo() { return m_foo; }
>
>and then go on to replicate most of the contents of std::vector.
>Wheeee! Accessors! Const-correct ones! Wheee! 300 lines of code in one
>hour. The manager must be realy proud of me! Thanks. I think I'll
>pass.[/color]
Actually those 300 lines of code can save you *lots* of time. If
m_foo is public, what will happen when you will have to change
your class's implementation? Imagine this:
class T_Wrapper {
// no const-correctness in this class because it isn't
// what we're talking about
public:
T foo;
void print() {
string s = makeStringRepresentation();
cout << s;
}
string makeStringRepresentation() {
// lots of time-consuming processing here
}
};
And in the client code:
void f(T_Wrapper& tw) {
tw.foo = someValue;
tw.print();
}
One day you decide to optimize makeStringRepresentation():
class T_Wrapper {
public:
T foo;
string cachedStringRep;
bool cacheIsUpToDate;
void print() {
if ( ! cacheIsUpToDate) {
cachedStringRep = makeStringRepresentation();
cacheIsUpToDate = true;
}
cout << cachedStringRep;
}
string makeStringRepresentation() {
// same as above
}
void setFoo(T newFoo) {
foo = newFoo;
cacheIsUpToDate = false; // let's not forget this
}
};
Well, now f() is broken, because it changes foo without setting
cacheIsUpToDate to false. And so is all your client code. You
have to rewrite (or at least check) *everything*.
I think data members should be private even if they are part of
the interface. Unless, of course, you have some good reason to
do otherwise.
And, by the way, const-correctness is useful too...
;-)
--
Andre Heinen
My address is "a dot heinen at europeanlink dot com"
