> | > No... accessor methods.
> | >
> | > I will probably put that down as a coding rule later: "Class variables
> | > shall always be private."
> |
> | I still think that class variables should be accessible *inside* a Class.
> | I understand that they shouldn't be accessible from outside, therefore I
> | put them there protected and not public!
My opinion:
'public <-> protected' and 'protected <-> private' are two different
things. But both are in some way trade off between "(perceived?)
security and maintainability" and "effort and maintainability".
Note that maintainability shows up on both sides ;-}
If you desperately need to protect against abuse of your classes, you need
"private". On the other hand, the most likely "abuser" are yourself, so
you pay (writing accessor functions, compile times, probably run time) for
something you might not _really_ need.
I usually consider "protected" member vars good enough for most practical
reasons, especially if they are used only within the class's hierararchy
(i.e. don't have public accessors).
I don't really like constructs like
count( count() + 1);
and _much_ prefer
++count_;
The latter clearly states what I want in half the verbosity.
(and having "shortcuts" like incCount() only adds to the annoyance of
needing to write accessors).
My personal rule is more or less "Try hard to make it private _without_
direct accessor method. If this does not work, relax one of the
restrictions - starting with 'private'"
Andre'
--
André Pönitz ............................................. [EMAIL PROTECTED]
