Hello all in the Lingo OOP coven-
I ran across an old thread from April on OOP basics. I wish to point out
at this time that I have not been studying it SINCE April...
I have included Irv Kalb's example about accessor methods below. I
understand it. No, really. At the risk of having to go through the usual
acolyte initiation ritual of pushing uninitiated variables up the stairs
with my nose, I'd like to pose a question, though:
In Irv's example below, there's an accessor handler, mGetNumberOfApples,
that returns info about a specific property.
If my behavior has, say, 5 properties I want to access, I'd be tempted
to write an all-round handler like:
on getProperty me, prop
return value(prop)
end
which could be accessed with:
theValueI_need = sendSprite(whateverSprite, #getProperty,
"propertyName")
However, this would seem to be a rash and dangerous balance on the edge
of broken encapsulation. 'Cuz, I need to know the property name. It just
seems to me that if I know the handler name, then I'm not ridiculously
far from knowing the property name.
The alternative would be to write 5 almost identical handlers that
specifically return property values.
Is that pure OOP?
Sincerely,
Clars Danvold
architect, designer, programmer
Irv Kalb wrote:
<snip>
...example.
>
> -- Behavior 1
>
> -- some code
> x = (sprite spriteNum).foo
> -- some more code using X
>
> -- Behavior 2
> property foo
>
> on beginSprite me
> foo = 5
> end
>
> The above code will work fine. But ... some day you realize that
> "foo" shouldn't really be "foo", it should be "bar". Given the
> above, if you change "foo" in Behavior 2 to "bar" you have just
> inadvertantly created an error. When this runs, Behavior 1 will give
> you an error because there is no "foo" in Behavior 2. Anywhere in
> the program where you reached in and used the property variable foo
> you will have to change it to bar.
>
> Now instead, lets see what happens if you had coded it this way:
>
> -- Behavior 1
>
> -- some code
> x = sendSprite(spriteNum, #mGetNumberOfApples)
> -- some more code using X
>
> -- Behavior 2
> property foo
>
> on beginSprite me
> foo = 5
> end
>
> on mGetNumberOfApples me
> return foo
> end
>
> Now you can change "foo" to "bar" in Behavior 2 and everything will
> work fine. There will no other affect on the rest of the program.
>
> This may seem like a subtle thing, but the point is that one of the
> key concepts in OOP is that the effect of your changes should be
> minimized. By clearly defining the "interfaces" - the way that these
> behaviors (or objects) communicate, then you can change their
> implementations without affecting the rest of the system.
>
> Hope this helps,
>
> Irv
[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!]
