At 11:10 AM +0100 10/12/00, Jon Rowe wrote:
>hi all
>
>
>1. When, if ever, is it 'allowable' to access a property without using
>an accessor method. e.g. I have a general object manager called HQ which
>holds references to all my other objects (speechMngr, animationMngr
>etc.) Now say I want to make a call to the speechMngr, is it OK to say
>
> call(#speak, HQ.speechMngr, "words...")
>
>or should I use an accessor method:
>
> pMySpeaker = call(#mGetSpeechObject, HQ)
>
>then use
>
> call(#speak, pMySpeaker , "words...")
>
I have written many times about this topic before. Mark laid out a
very good case for why accessor methods should always be used.
That said, if your HQ object has an object reference to your speech
object, I wouldn't use either of the approaches above. Instead, if
your only "hook" is the HQ object, then I would simply call a method
in the HQ object to speak words, and have the HQ object pass this
call onto to the speech object. For example, when you want to say
something, use this:
HQ.mMakeItTalk("words ... ")
Then in your HQ object add:
on mMakeItTalk whatToSay
speechMngr.speak(whatToSay)
end
The difference is that in either of your approaches above, you are
assuming an implementation within your HQ object. In my approach,
you ask the HQ object to say something, and the HQ object figures out
how to do it - in this case, passing it on to a sub-object.
<Warning: OOP heresy follows>
As far as getting rid of your global HQ object, Robert W gave a great
explanation of how to do that. But the question is why is that
important? I have seen discussions like this where programmers want
to create one "god" object which creates all other objects in the
system. And for pure OOP style, this is a good thing.
But we live in the real world and we need to get products out the
door. The way that I create OOP systems, I amost always have a few
global objects around that are accessable from everywhere. In cases
where I know that there will only be one object of a type (and this
is the key), I instantiate them from a prepare movie handler, and
save the object reference into a global variables. For example, if I
have a need for one navigation object and one tracker object, I will
do:
global goNav -- global object Navigation
global goTracker -- global object Tracker
on prepareMovie
goNav = new(script "Nav")
goNav = new(script "Tracker")
end
-- And then clean it up on the way out
on stopMovie
goNav.mCleanUp() -- give it a chance to clean up after itself
goNav = VOID
goTracker.mCleanUp() -- give it a chance to clean up after itself
goTracker = VOID
end
Now I know that anywhere in my movie I need to make calls to the
Tracker or the Nav object, I can always get to them by just using the
globals goNav and goTracker. I then think of the Nav object and the
Tracker object as completely independant "programs" whose code (but
not data) is directly accessable from anywhere in the rest of the
main program. This approach makes my life much easier - and
eliminates the need for a single "god" object whether it is global or
not.
</heresy>
Irv
--
Lingo / Director / Shockwave development for all occasions.
(Over two millions lines of Lingo code served!)
[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!]
