This 'Getters' and 'setters' debate comes up pretty regularly.
I'm prepared to fly the OOP flag from time to time, but I've always felt
a little uncomfortable with this idea of having a 'getter' and 'setter'
for each 'public' property.
I've never been able to come up with really good reasons why a generic
'getter' and a generic 'setter' for all properties aren't just as clean.
(Jakob mentioned some good ones about scope during debugging, but
they're not *that* good). Something grates inside me. What is it? What
is it?
Most of all, it strikes me that if an object needs to see another
object's property, then something is wrong with the encapsulation.
Surely, objects provide *services*, not access to their guts.
Well, I found a very interesting treatment of this issue. (Java related,
but it's mostly theory). Have a read through this;
http://www.javaworld.com/jw-07-1999/jw-07-toolbox.html
and here's a quote to whet your appetite:
> here are some rules of thumb that you can apply to see if you're really
> looking at an object-oriented system:
>
> 1.All data is private. Period.
> (This rule applies to all implementation details, not just the data.)
>
> 2.get and set functions are evil.
> (They're just elaborate ways to make the data public.)
>
> 3.Never ask an object for the information you need to do something;
> rather, ask the object that has the information to
> do the work for you.
>
> 4.It must be possible to make any change to the way an object
> is implemented, no matter how significant that change may be,
> by modifying the single class that defines that object.
>
>5.All objects must provide their own UI.
A bit extreme perhaps, but, well... just read it.
--
_____________
Brennan Young
Artist, Composer and Multimedia programmer
mailto:[EMAIL PROTECTED]
[To remove yourself from this list, or to change to digest mode, go to
http://www.penworks.com/LUJ/lingo-l.cgi To post messages to the list,
email [EMAIL PROTECTED] (Problems, email [EMAIL PROTECTED])
Lingo-L is for learning and helping with programming Lingo. Thanks!]
