My preference is usually option 3, using an event. It means you can use your ball in other situations, where that "call" back to the root may or may not be necessary. Regarding cleaning up references in event listeners, you can use a "weak reference" when you call addEventListener(). Also, I often find that existing flash or flex events match the nature of what I want to express, so I re-use theirs sometimes which saves writing a new event class.
Option 4 would be to make MyGame implement some interface (Game? IGame?) which specifies that function. Then the BouncingBall constructor is passed a reference to the interface instead of the whole MyGame class. Same as option 2, really, but this way it's plausible that you would implement the interface with some other game-like class and use BouncingBall in that. Option 5 would be to pass a Function reference into the constructor of BouncingBall. This is very generic, like the event solution, but has a few downsides: 1) function specifications are not maintained by the compiler when you pass Function references, so if you write a bug into the call of the function, you'll get a run-time error instead of a compile-time error. 2) Exactly one object can "listen" for this function call, unlike an event, which can be listened for by any number of clients. I often use Option 5 for success and failure callbacks when something won't complete right away. Dave On Thu, Feb 5, 2009 at 9:44 AM, Todd Kerpelman <[email protected]> wrote: > Hey, FlashCoders. > > I'm wondering if you can help me out with a general style question that I > keep running into. Let's say I've got a setup like this... > > class MyGame extends MovieClip > - It creates a "camera" sprite that I can add children into > - It then creates a "Bouncing Ball" object with the "camera" sprite as > the parent to use. > > class BouncingBall > { > public function BouncingBall(parentToUse:DisplayObjectContainer) > { > // Create member variable _mySprite:Sprite and add it to my parentToUse > //... > } > } > > For reasons I won't get into unless you're really interested, BouncingBall > does NOT extend Sprite, it simply contains a sprite. > > So MyGame has a camera as a child. That camera has my > bouncingBall._mySprite > as a child. > > The question is this: I want the BouncingBall sprite to occasionally call a > function in MyGame. What's the best way to do this? > > *Option 1:* Within BouncingBall, just call... > > MyGame(_mySprite.root).foo(_myVar); > > This works, but it strikes me as a little unnatural, since I have to dig > into my member variable and get its root. Also, I'm not sure this works if > my game were to be imported by some larger, wrapper class. > > *Option 2: *My constructor for BouncingBall should contain two variables > > public function BouncingBall (var parentToUse:DisplayObjectContainer, var > gameApplication:MyGame) > > I store gameApplication as a member variable, and use it later... > > _myGame.foo(_myVar); > > This is my current solution, but the idea of passing a parent and the game > application to the constructor strikes me as slightly redundant, and, like > Option 1, it tightly couples my BouncingBall object to my main application. > > *Option 3:* I create a custom event, dispatch that event, and create a > listener in MyGame rather than call a function directly. > > I'm guessing this is the best way to go theoretically, and will allow me to > reuse my BouncingBall object in other applications, but it's a lot of extra > code, and I constantly worry about not property cleaning up event > listeners. > > > I'm sure all of you have encountered this situation before. So what do you > generally do? Is there a fourth, totally obvious option that I'm > overlooking? > > Thanks! > > --Todd > _______________________________________________ > Flashcoders mailing list > [email protected] > http://chattyfig.figleaf.com/mailman/listinfo/flashcoders > _______________________________________________ Flashcoders mailing list [email protected] http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
