🚀 go-pugleaf

martelli@cadlab.cadlab.it (Alex Martelli) wrote:

>"Juan Carlos Rodriguez" <JUANCA@sergied.dis.ulpgc.es> writes:

>>     The new access way will eliminate the tedious work of
>>write functions to protect the external access to interesting
>>class attributes.

>Providing access functions to class attributes is a particular style,
>and generally _not_ a particularly good one -- in my experience, it
>tends to result from under-design.  Why does everybody need read access
>to those attributes -- why are the attributes in the class
>_interface_?  Sure, there _are_ cases in which a property of an object
>that its clients will want to query happens to be best _implemented_ as
>a data member of the object's class, but how frequent is such a
>_coincidence_?  Surely not frequent enough, in good OO design style, to
>make it _tedious_ to provide the accessor explicitly in those special
>cases!

I am a little uneasy with the idea that a reasonable design technique should be
tedious to discourage its overuse.  However, I don't think that the problem
mentioned is bad enough to add another keyword.  But if the problem were severe
enough to merit a language change, I think there is a better approach.

The ideal would be to eliminate altogether accessor functions from the class
interface.  Whether an attribute of a class is implemented as a variable or a
function is not important to the source interface.  Instead, there would simply
be attributes, which could be accessed (i.e. square.Area).  Whether these were
implemented as a data member or as a function (i.e. { return height * width; })
is not particularly relevent to the caller, so why should he specify "Area()"
rather than simply "Area".

P.S. I am not certain that I am using the best terminology here.  If anyone
knows of more "official" terminology, I would like to hear it.  When I say
"source interface", I mean the way the caller accesses an attribute in the
source code.  This is distinguished from the "object interface", which is the
way that the compiled object code accesses the attribute.  In the "Area"
example above, changing an attribute from a data member to a function changes
the object interface without changing the source interface.  I current systems,
this would require a recompile, but would not require any source changes.

John McGrath



---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]