Organization
Another form of control you have with OOP is organization. Once you start writing classes and begin forming a collection of reusable class definitions, you'd want to be able to easily include them in future projects and movies should you need them. The easiest way to do this is by writing your class definitions in external text files (.as extension is recommended for actionscript text files) and then using the #include command.

What #include does is reads the textfile specified into the Flash movie as though it were written in place of the #include line. This happens when you publish or test your movie so this included text does not take up space in your .fla file, but is a part of your .swf. It is often assumed that a Flash movie will read a included file in this manner when it is played. That's not the case. It is put within the swf when it is made. So you will not need to have the included file on the server for the movie to function properly; nor would you be able to change code in a Flash movie by changing a file included in this manner - at least not without re-publishing the movie so it can be re-inserted into the .swf file.

The following takes the text (Actionscript code) contained in the file source/myClass.as and includes it the movie at the point this line was written.

#include "source/myClass.as"

There are two core directories that #include looks for files in this manner. One is the directory your Flash movie is saved. The other is in an include folder in your Flash install directory. In the previous example, if the movie using that lie of code was saved on the C:\ drive of a Windows machine, then the two places #include would look for myClass.as would be

C:\source

and

[Flash MX install directory]\Configuration\Include\source

Keeping simple common class definitions in Flash's include directory can be a good idea. However, if distributing the source files or if in collaboration with others, it would be wiser to keep the files all together along with the .fla itself. This makes it easier to just package that single working directory for distribution among others. Also, by keeping these files separate, it makes it easy to add project specific amendments to these included classes without affecting other movies which may otherwise also be using the same files thereby reducing the risk of confliction when implementing those changes.

With that you may also want to consider using fairly unique names for you classes. For instance, lets say you found a good implementation of a certain class you need for a project you are working on but its class name shares the same name as one which you are already using. What then? You would have to rename one of those classes and change each instance of its use in order to be able to use both. One way of avoiding this is by creating a unique namespace for your personal classes to live. This is often simply an object for your classes to live - an object who's name is your domain name and therefore unique. An example would be

uniqueInstance = new com.kirupa.uniqueClass();

You can learn more about namespaces in Flash from Colin Moock's FlashForward 2003 lecture.

		Index	Next Section