11.3 The Classes

Because we're building a pure OOP application, all of our application's content is created by its classes. In Flash, most applications are visual and include graphical user interfaces. Hence, the classes of an OOP Flash application typically create and manage user interface components . But in our example, we'll include only two sample classes. For now, our focus is the generic structure of our framework, so neither class creates any visuals or performs any specific practical task. To emphasize the generic nature of our framework, we'll name our classes A and B . (In Chapter 12, we'll see how to create components and manage a user interface based on the present skeletal framework.)

An OOP application can have any number of classes, but only one of them is used to start the application in motion. In our example, class A starts the application. Class A has a class method, generically named main( ) . By convention, the main( ) method contains an application's startup code. In an actual application, class A would be replaced by a specific class whose main( ) method performs a specific startup duty. For example, in a quiz application, the primary class might be Quiz , and the main( ) method might initialize the quiz and display the quiz's first question. In a chat application, the primary class might be ChatClient , and the main( ) method might connect to the server. In both cases, the remainder of the application cascades from that first invocation of main( ) . For example, an answer to question 1 would cause question 2 to appear, or a successful connection to the server would cause a chat interface to appear.

For the sake of our example framework, we'll consider A 's startup task to be simply creating an instance of B .

Our use of the class method named main( ) follows Java's methodology exactly. But in Flash, the main( ) method is an optional convention. In Java, it is a requirement of the language. In Java, main( ) is invoked automatically, whereas in Flash, you must manually call main( ) from, say, the first frame of the timeline following the application's preloader.

We'll store our classes in the package com.somedomain . In your application, you should change com.somedomain to match your web site's domain name. For example, I create all my classes under the package org. moock because my domain name is moock.org .

To create the directories for the com.somedomain package, follow these steps:

1. In the AppName/source directory, create a subdirectory named com .

2. In the AppName/source/com directory, create a subdirectory named somedomain .

To create class A , follow these steps if you're using Flash MX Professional 2004. If you're using Flash MX 2004 (standard edition), use an external text editor to create the .as class file following similar steps:

1. In Flash MX Professional 2004, choose File New.

2. Click OK. The script editor launches with an empty file.

3. Enter the following code into the script editor:

    import com.somedomain.B; class com.somedomain.A {   private static var bInstance:B;   public function A ( ) {     // In this example, class   A   's constructor is not used.   }   public static function main ( ):Void {     trace("Starting application.");     bInstance = new B( );   } } 

   
   

4. Choose File Save As.

5. In the Save As dialog box, specify A.as as the filename, and save the file in the directory: AppName/source/com/somedomain .

Similarly, to create class B , use Flash MX Professional 2004 or an external text editor to create the B.as file in the AppName/source/com/somedomain folder with the following content:

 class com.somedomain.B {   public function B ( ) {     trace("An instance of class B was constructed.");   } } 

Notice that in our example framework we store the files for our class hierarchy under the AppName /source subdirectory. That's a reasonable place to store the files, but it's not mandatory. The class files could theoretically go anywhere . As long as the directory in which they reside is added to the global or document classpath, the classes will be accessible to timeline code and other ActionScript classes. For information on classpaths, see "Package Access and the Classpath" in Chapter 9. For information on storing classes in a central repository, see Chapter 14.