Additionally, you should take a look at what the code is doing.
Why does Bouncing Ball have to call something in the parent?
Is it some sort of notification? ("I've finished animating/I've hit a
wall!"). In which case an event is definitely the right solution.
Is it to gain information of some sort? In which case, an event won't
do it. Consider passing that information in at creation of the ball.
If that doesn't make sense - you need to query something in the parent
at regular intervals - consider whether the code inside BouncingBall
really belongs in BouncingBall. Are you sure whatever it's doing
shouldn't be in the parent class instead? Think about black box models
- for example, if it's calling the parent to query about collision
detection or some such, it's not the ball's _job_ to know whether it's
collided with anything; it's the parent's.
If you really need to talk to the parent/regularly fetch changing
information from the parent and it _is_ the ball's business to do it,
I'd be looking at using interfaces if I wanted everything to be
properly decoupled.
Hope that helps,
Ian
On Thu, Feb 5, 2009 at 7:07 PM, Merrill, Jason
<[email protected]> wrote:
>>>I think I whip up custom events more than almost anything else.
>
> Yup - me too - in fact, in FlashDevelop, I have a nice event template in the
> form of a code snippet for a new custom events I use all the time:
>
> package
> {
> import flash.events.Event;
>
> public class extends Event
> {
> public static var :String = "";
>
> public function (type:String, bubbles:Boolean=false,
> cancelable:Boolean=false)
> {
> super(type, bubbles, cancelable);
> }
> }
>
> }
>
_______________________________________________
Flashcoders mailing list
[email protected]
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
