Peter Dimov wrote:
From: "Edward Diener"
David Abrahams wrote:
"Edward Diener" <eddielee@tropicsoft.com> 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.