AS3 Document class and package classes tipas asked.

[humbucker]

Hello,

I'm learning AS3 for some weeks now and I'm using a single document class actionscript to pilot my flash file.

I see in different components or example files that sometimes a project uses differents classes (one class that handles the backgrounds, one class for navigation)...

My question : what's the good use of multiple classes and how can I make them communicate if I need the value of one function from another class file ??

Thank you !!

[senocular]

Classes define objects. If you ever create an object in code, you're creating an instance of a class. Ever use arrays? They too are defined in classes. You would want to create your own classes when you need objects that aren't already pre-defined in the core set of definitions Flash provides you. For example, if you have a movie clip that should behave a certain way, that movie clip could be an instance of its own specific, user-defined (you) class.

Communication can be handled many different ways. This is usually through references and/or events. Generally speaking, you usually have a parent object and a child object where the parent is responsible for creating the child. For example, a Fan object is responsible for creating a FanBlades object. In doing so, the Fan inherently has a direct reference to the FanBlades instance because it created it (and presumably has it stored in a variable of the Fan class). FanBlades itself doesn't necessarily have to have a reference to Fan, though Fan can provide it one if it wants to. When you call Fan.turnOn(), The Fan class can access its FanBlades instance from its member variable and tell it to spin. As the parent object Fan has control over the FanBlades instance. That instance, however, should not be able to tell Fan what to do. But there may be times when it needs to inform Fan of things that occurred. For example, if someone throws feces at the Fan and it hits the blades, the FanBlades instance can dispatch a custom event called ****_HITS_THE_FAN, and if the Fan object cared to listen for that event, it can react and turn off, or do whatever it wants. The idea there is that the child object can inform the parent of things going on, but its not directly forcing it to do anything. If FanBlades was given a reference to the Fan object when it was created, it could, instead of sending an event, call Fan.turnOff() directly. But then you have a situation where Fan is not in contol of itself.

Events are the typical way of handling communication like this, though tight coupling through circular references (each object references the other directly) can also be used depending on your situation.