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. 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 ;-)