Class design: accessing "private" members

[Frank V. Castellucci]

Jerome Quelin wrote:
> 
> "Alex Martelli" <alex at magenta.com> wrote:
> >By calling the accessors, rather than accessing the data
> >directly, you ensure that if somebody overrides the
> >accessor functions in a derived class you'll be calling
> >the derived-class versions of those functions.  If that is
> >what you want (one direction along which you want to let
> >inheritors of your class extend or tweak behaviour), then
> >it's probably worth the overhead you mention.
> The class isn't to be derived any further. It's a class that I use in an
> application, and that may be imported in some other applications, but not to be
> inherited.
> 
> Then, is it better/cleaner to access private members with accessors or not?
> Is it a matter of style? Or are there hidden caveheats using (or not using)
> accessors? It _seems_ cleaner to use accessors, but man, it's quite awkward.
> 
> Jerome
> --
> jerome.quelin at insalien.org

As you really have no way to "prohibit" further derivation (unless I
missed the "final" keyword in the reference), using your accessors and
praying that anyone over-riding the accessor/mutator methods does the
proper thing would be my direction.

-- 
Frank V. Castellucci
http://corelinux.sourceforge.net
OOA/OOD/C++ Standards and Guidelines for Linux
http://PythPat.sourceforge.net
Pythons Pattern Package