"Karina Steffens" <[EMAIL PROTECTED]> wrote
> The way I see it, the moment you define an accessor method in your object,
> you automatically declare the property it accesses as public. That's the big
> difference. You don't just grab any old property from an object, as you
> would with direct access, instead you politely ask for a property that the
> object "decided" that it's willing to give.
> Also, you don't just get the property: By using a "getter" method you allow
> the object to decide what information it wants to give you. It can either
> give you the value of it's property "as-is", or make some pre-calculations
> and return a value that isn't even stored as part of it's properties.
If the handler makes some modifications, then maybe it's a service, but I'd
still argue that it's better for the one providing the data to be the active messenger.
The point is if an object has a handler like
on getMovietime me
return sprite(spritenum).movietime
end
... then 'movietime' is not encapsulated properly. You then look at who is
asking for this value and why. Maybe it can be expressed in another way.
This is especially important if the data being 'got' is passed by reference
(such as a list), because (of course) the getter is suddenly in a position
to set without the gettee knowing about it.
In the Quicktime wrapper example, I see no reason why the slider should
'know' about the Quicktime movie, and I see no reason for the QT wrapper to
know how 'progress' is expressed by the object it calls back, which might
just as well be a field displaying an integer.
If the slider is asking the Quicktime sprite for movietime, or calling the
Quicktime wrapper's getMovietime() function, then the slider is not general
enough to be used for other things than Quicktime controller sliders.
> Same with setters: You can pass the object whatever info you want, and it's
> then the object's decision what to do with it. I really can't see the
> difference between that and writing any other kind of public method.
It's about black box implementations really. The moment you have getters and
setters the outside world already 'knows too much' about whats going on
inside. Like much of OOP, it's partly a matter of style, but arguably it
does make for more robust designs to hide the properties completely, so that
their presence is not even inferred by 'getter' and 'setter' handlers
(whether or not you actually have 'getter' and 'setter' handlers).
> In my own work, I often have objects who's main function is to give out
> information. For example, I have an object that stores a city-map grid. Most
> of it's methods are getters: Whenever another object needs to have a "look"
> at the map, it calls one of the getters and receives the information. Some
> of the getters just return information, others calculate stuff first and
> then send out the results. They don't _do_ anything with the information
> themselves, their sole purpose is to give it out to other objects. I don't
> see anything "evil" about that >:->
Neither do I, necessarily. The object may be providing a service there. The
question is how the 'having a look' is understood by the outside world. If
you have a 'getter' like this:
on getGridUnit me, x, y
return myGrid[x][y]
end
...you might ask yourself whether the code calling this function should not
be a part of the grid black box instead, providing whatever it's doing as an
additional service.
--
_____________
Brennan Young
Artist, Composer and Multimedia programmer
mailto:[EMAIL PROTECTED]
"I suppose if I'm honest, I use my penis as a sort of car substitute."
-Stephen Fry
[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!]
