Re: Why are member functions allowed to access private data members of a ?class?

Dwight Army of Champions <dwightarmyofchampions@hotmail.com> wrote:


  That's a gross oversimplification, and in fact the overuse of accessors
can often lead to bad design.

  While not always completely possible, and in many cases not completely
necessary, it's nevertheless a good design principle that the public
interface of a class should be as abstract as possible and reveal as
little as possible about its internal implementation details.

  Public member variables are usually considered bad design because they
expose internal implementation details to the outside, hence potentially
causing outside code to start *depending* on those implementation details,
making changing those details without breaking existing code harder.

  Accessor functions are only *slightly* better than public member variables,
especially if there are many such accessors. Now the outside code will not
depend on the member variables directly, but it will depend on the accessors.
Hence removing, renaming or doing other kinds of changes to these accessors
will probably break existing code. (It's not completely unusual that when
refactoring a class its member variables are redesigned from scratch, hence
often making some of the accessors obsolete or in need of heavy modification
which changes significantly their signature.)

  The ideal situation is when the public interface of the class is so
abstract that the outside code depends as little as possible on these
internal implementation details. This makes it much easier to change these
details without having to change the public interface and hence breaking
existing code. (Naturally, as I already said, this is not always completely
possible, but it would nevertheless be the ideal case.)

  There are some languages (such as C#) where all public member variables
can be replaced with accessors without any change in syntax in the outside
code. While this might sound handy at first, my personal opinion is that
this kind of language feature is actually a mistake which, rather ironically,
often leads to rigid code which is hard to refactor and modify. That's
because the feature induces programmers to put member variables in the
public interface of classes (thinking "I can always replace them with
accessors if needed, so it doesn't matter"), making outside code depend
on these implementation details, thus making it harder to change these
details later. In other words, this feature often induces people to write
less abstract code, to their own detriment.


  I find that question rather strange. How should they access their own
data then? If your answer is "through accessors", then exactly how do you
implement those accessors? Accessors *are* member functions, after all.
If member functions couldn't access member variables directly, then you
couldn't implement accessors.

  (Yes, accessors must be regular member functions. That's the whole idea
of an accessor: That you could modify it to do something completely
different than simply return/set a member variable. Heck, the equivalent
member variable might not actually exist at all.)

  From a design point of view, restricting access rights exists to stop
outside code from accessing member variables directly, not to stop inside
code from doing so. Inside code is restricted to a single module and thus
is well encapsulated, making refactoring easier.


  Why would this be so?


  And how do you suggest those accessors and mutators be implemented?