AS2 OOP: Class File Management
         by senocular  

Packages
Packages are basically a collection of files and folders all kept and maintained within one single directory. This one directory is what's known as the package. There's nothing special about this directory folder in and of itself. It's just a normal directory just like all the others on your computer. What is special is the collection of .as files within that directory and its subdirectories. These files are aware of their directory structure within their "package". Not only are they aware of it, but they also use that structure to define their object scope within Flash. What's more is that, as a package, Flash recognizes all of its contents as long as the package directory resides within a directory specified in the classpath. All subdirectories within that package are automatically included (assuming the package folder lies within a directory in the classpath).

You might want to use packages when you want to collectively classify a group of similar or relating classes. These classes can then be kept in one package and easily be added all at once, no matter where within the package directory structure they are saved, just by having the folder within a directory specified in your classpath. More importantly, packages create namespaces, or object scope of existence, for your definitions when used by Flash making them very useful for distributed code (by default, all classes are defined directly in the _global object).

Now, when I say .as files in a package directory are aware of their directory structure, this doesn't mean that they are sentient beings that suddenly wake up from some mysterious lethargy and miraculously gain this insight. No; you have to give it to them. This is done within the definition of each .as file in a package. Each file needs to have its definition reflect its location within the directory structure of its associated package. This is done using dot syntax to outline the definition's location within the package directory. For instance, the following is a class buried within an Enemies package used in a Flash game.

class Enemies.Bosses.Bombatoss {
var lifeforce:Number;
 
function Bombatoss(life:Number) {
lifeforce = life;
}
// ...
}

This particular class is in the file Bombatoss.as. It resides in the directory

Game\Enemies\Bosses

Where Game is a directory specified in a Flash document's classpath and Enemies is the package name. Notice that everything is normal for a class aside from its name following the class keyword. This is where the class identifies itself as being part of the package and no where else. The constructor is defined normally.

The new name given to the Bombatoss class looks a little familiar - much like object referencing within Flash, as if Bosses.Bombatoss was located in an object named Bosses which was itself located in an object named Enemies. Funny how that is, right? Well if you haven't guessed it already, that is how it will end up in Flash as well. This is where packages provide you with namespaces for your classes as they are used in Flash.

[ game package contains subdirectories of accessible as files ]

When used in Flash, packaged classes will exist within objects as dictated by they're position in the directory structure of the package folder and as reflected by their class definition name. You would want to be sure that your classes in these packages correctly reference themselves and that you correctly reference them when using them in Flash. Bear in mind that because directories in your package folder will be used as Flash object names, they need to have valid Flash variable names and cannot share the name of other classes in the directory in which it resides.

var badGuy:Enemies.Bosses.Bombatoss = new Enemies.Bosses.Bombatoss(100);

This is great for keeping classes separated and confined within their own objects or namespaces. This can be especially useful if you ever run into a situation where you might have two similarly named classes. If kept within a uniquely identified package, confliction will be less likely to occur. But, Ok. So, it's a little long, but that's why the good lord blessed us with the import command.

 




SUPPORTERS:

kirupa.com's fast and reliable hosting provided by Media Temple.