[boost] Re: Re: class properties: request forpromotionand/orfastreview.

From: Edward Diener (eddielee_at_[hidden])
Date: 2004-05-24 20:39:43

Peter Dimov wrote:
> From: "Edward Diener"
>> 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.
>
> It doesn't matter. Properties represent degrees of freedom. They don't
> describe dependent data well.
>
> As a relatively simple example, consider a pair of integers (x, y)
> that has an invariant of x*x + y*y = 25, and try to move from (3, 4)
> to (4, 3) by using the X and Y properties.

As an even simpler example, and I think more realistic example, consider a
pair of integers ( xleft and xright ) which describe the coordinate
boundaries of the x-axis of a rectangle, along with another property which
is the width of the rectangle. Changing any of the integers will change the
width while changing the width will change the xright integer. Even with all
 these interactions, the idea of being able to change the position and width
by changing any of these properties is not that difficult to fathom.

Of course as in your example, when two or more values have a more complex
relationship they are not very good candidates for properties. Properties
should be used assiduously, and certainly not every data value which a class
contains should be a property. In your example I would hardly think that the
designer of the class would want x or y to be directly manipulated in any
way.

My general argument to Mr. Abrahams is that I don't think that properties,
or even data itself, has much to do with the ability to use abstraction to
model concepts in OO areas. As such I don't see properties as an impediment
to good OO design, while I do agree that like many concepts taken too
literally, it is subject to abuse. Strangely enough I have found the
greatest abuse of properties in JSP with JavaBeans, where the official
mantra seems to be that changing and accessing properties is the way to
program web applications. Ugh !!! An obvious case of the idea of properties
carried to a bad extreme.