[boost] Re: class properties: request for promotion and/orfastreview.

From: Edward Diener (eddielee_at_[hidden])
Date: 2004-05-23 15:31:08

David Abrahams wrote:
> "Edward Diener" <eddielee_at_[hidden]> writes:
>
>>> If you are making designs that would normally have a lot of getters
>>> and setters, it suggests that they may have an insufficient level of
>>> abstraction.  Of course, that isn't neccessarily the case -- but it
>>> does seem to be the rule in my code.  I personally don't have a need
>>> for this facility and I don't think I want a library that would
>>> encourage that style.
>>
>> I don't see what getters and setters have to do with levels of
>> abstraction.  Needless to say I see nothing wrong with the style
>> that uses properties, but since you didn't say what bothers you
>> about that style I can't answer for why you don't like it. Care to
>> explain ?
>
> When classes have a lot of getters and setters or, equivalently,
> exposed properties that are just reflections of underlying data
> members, they usually represent just a collection of exposed data
> values rather than a higher level of abstraction.

Properties do not have to be data members at all but just values may be set
anywhere, ie. a file on disk or a database, and a number of properties may
refer to a single underlying object within the actual object having the
property. As such I don't think that having many properties necessarily is
any impediment to a level of abstraction. Furthermore properties of a
derived class may actually affect some underlying functionality of a base
class, which I don't see as any more an impediment to designing a good class
hierarchy than calling a member function which uses base class functions to
achieve its functionality.

It could be equally as right to say that a class having many member
functions does not represent a higher level of abstraction, but I think that
this is an incorrect argument also. Cleary frameworks such as the VCL and
.NET can present fairly high levels of abstraction for whatever concepts
they are modeling for application development and each use properties very
effectively to make it easier to program their respective frameworks.

I do agree that an overuse of properties is a theoretical danger to
programmers who may become so enamored of them that they substitute
functionality for setting values and thus hide what should be functionality
behind an obfuscated interface. But C++ has always been a language which has
promoted best programming practices rather than protection of novices and I
see no reason not to do this in the matter of properties also.

My main interest in properties is to make it easier for future RAD
functionality in C++ when reflection becomes a reality, rather than in
syntactic sugar. With all that said about syntactic sugar, it is obviously
safer to enable data member syntax with properties, whose underlying
function can control whatever changes can be made, than to use raw data
members. I do think that data member syntax better mirrors actually changing
and access of values within a class than member functions with Set... and
Get.. semantics.

>
> I haven't read through this to see if I agree with any of the points
> being made, but you can read an article on the subject here:
>
> http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html?
>
> and a pretty comprehensive discussion here:
>
>
http://discuss.fogcreek.com/joelonsoftware/default.asp?cmd=show&ixPost=70526
>
> To the extent to which properties (which I *do* think have a place in
> good software) are just syntactic sugar for getters/setters, the same
> arguments apply.
>
> You can of course make up your own mind about this stuff ;-)