Writing a lot of redundant handlers is almost always 'pure OOP'. I
think the meaning of not accessing the properties directly is that
you will be allowed to change the inner workings of the script a lot
without changing in any of the calling handlers.
You can change the prop names, data type, anything - as long as the
handler that returns the prop still converts the data to the old
format before returning it to the caller.
Also you never need to care about using the same structure of your
data in different scripts, it will be converted when haning over the
data.
-Andreas
>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!]
[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!]
