Flash Professional CS5 now offers code completion and color syntax highlighting for custom classes as well as built-in ActionScript classes. It accomplishes this by parsing all known classpaths and building a cache of all classes in these paths. A side effect of this feature is that the process of building the cache can become overwhelmed if there are too many classes to analyze. Therefore, try not to collect every class you have into one giant folder. Move applicable classes in and out of your folder, or create classpaths for smaller folders on a project-by-project basis. See the companion website for more information about this issue.

Here is a basic class you can use to represent a generic vehicle. We’ll call this class Vehicle, so the document name will be Vehicle.as, and the class will be saved in the same directory as your FLA. This class creates a vehicle and, when activated (by calling the go() method), increases the number of miles traveled and decreases the remaining gallons of gas after each enter frame event, tracing the result. It will show in the Output window how many miles the vehicle traveled, and how much fuel remains until it runs out of gas.

The class has four public properties, representing: gas mileage, available fuel, miles traveled, and a Boolean property called moving. The latter will enable functionality when true, and disable functionality when false. All the properties and methods in the class are public so other classes can see them. We’ll discuss that in further detail in a little while.

The constructor does only two things. It sets the properties for gas mileage and available fuel to the arguments passed in when the class was instantiated, and adds a listener to the vehicle that reacts to the enter frame event and calls the onLoop() method. Here’s what this portion of the class looks like:

1    package {
2
3        import flash.display.MovieClip;
4        import flash.events.Event;
5
6        public class Vehicle extends MovieClip {
7
8            public var gasMileage:Number;
9            public var fuelAvailable:Number;
10           public var milesTraveled:Number = 0;
11           public var moving:Boolean;
12
13           public function Vehicle(mpg:Number=21, fuel:Number=18.5) {
14               gasMileage = mpg;
15               fuelAvailable = fuel;
16               this.addEventListener(Event.ENTER_FRAME,
17                                     onLoop, false, 0, true);
18        }

Now let’s talk about the listener function in the next segment of the script. When the moving property is true, the onLoop() method first decrements the fuelAvailable property and increases the milesTraveled property by the value of the gasMileage property. So, if a vehicle claims a gas mileage rating of 21 miles per gallon, the car will travel 21 miles using 1 gallon of gas.

Next, the method checks to see if there’s less than one gallon of gas remaining. If so, the listener is removed. While the listener remains, the class will trace the vehicle object, miles it’s traveled, and remaining fuel to the output panel. In addition, the x coordinate of the class instance will be set to the current number of miles traveled, so any visual asset associated with this class will move. Because Vehicle inherits from MovieClip, the x property is accessible to Vehicle so it doesn’t have to be added anew. The effect is that a corresponding movie clip will move across the stage by pixels that correspond to miles driven.

Finally, the go() method, when called from outside the class, sets the moving Boolean property to true and allows the frame loop to work. This could be likened to starting the engine of the vehicle and driving. A more complex system might also provide a method for stopping the vehicle, as well as other features, but let’s keep this example simple.

1            public function onLoop(evt:Event):void {
2                if (moving) {
3                    fuelAvailable--;
4                    milesTraveled += gasMileage;
5                    if (fuelAvailable < 1) {
6                        this.removeEventListener(Event.ENTER_FRAME,
7                                    onLoop);
8                    }
9                    trace(this, milesTraveled, fuelAvailable);
10                   this.x = milesTraveled;
11                }
12            }
13
14            public function go():void {
15                moving = true;
16            }
17
18        }
19    }

To see this class in action, all you need to do is create an instance of the class, and call the go() method from that instance. If desired, you can also pass in a new value for gas mileage and available fuel. If there is a visual component to the instance (and we’ll see that soon), you would also add the instance to the display list. Here is an example of all three steps, including new values for the mpg and fuel parameters, as seen in the vehicle_only.fla source file. This is the last time in this chapter that we’ll use the timeline. For future examples, we’ll use a document class, moving all aspects of each example from the timeline to classes.

var vehicle:Vehicle = new Vehicle(21, 18);
addChild(vehicle);
vehicle.go();

When testing this file, the resulting trace lists the Vehicle class instance, the accumulating miles traveled, and the decreasing fuel available. After several iterations (condensed with the ellipsis in the sample that follows), the trace stops and shows the final number of miles traveled and less than one gallon of gas remaining.

//output
[object Vehicle] 21 17
[object Vehicle] 42 16
[object Vehicle] 63 15
...
[object Vehicle] 336 2
[object Vehicle] 357 1
[object Vehicle] 378 0

That’s fine if every vehicle you ever create is exactly the same kind of vehicle. However, the principle of inheritance allows you to subclass this Vehicle class, inheriting the attributes of Vehicle, but customizing each subclass into a specific kind of vehicle, like car and truck, as in the following examples.

The following two classes, Car (Car.as) and Truck (Truck.as), both extend Vehicle, so they inherit the properties and methods of Vehicle. Because the properties are inherited, they’re not included in the subclasses. Although these classes extend Vehicle, you can add unique properties and methods to make each class further specialized. For simplicity, we’ll add a method to each class to control an accessory—a sunroof for the car and a tailgate for the truck.

1    package {
2
3        public class Car extends Vehicle {
4
5            public function Car(mpg:Number, fuel:Number) {
6                gasMileage = mpg;
7                fuelAvailable = fuel;
8            }
9
10            public function openSunroof():void {
11                trace(this, "opened sunroof");
12            }
13        }
14    }

1    package {
2
3        public class Truck extends Vehicle {
4
5            public function Truck(mpg:Number, fuel:Number) {
6                gasMileage = mpg;
7                fuelAvailable = fuel;
8            }
9
10           public function lowerTailgate():void {
11               trace(this, "lowered tailgate");
12           }
13        }
14    }

Because of inheritance, the Vehicle class constructor is called implicitly when you create instances of the Car and Truck classes. This adds the enter frame listener so the cars and trucks can move, and then the Car and Truck class instances redefine the gasMileage and fuelAvailable public properties from the Vehicle class. It’s also possible to explicitly call the constructor, or other accessible method, of a superclass, which we’ll demonstrate when we discuss encapsulation.

Now we can revisit the FLA and, instead of instantiating the Vehicle class, we can create instances of the new Car and Truck subclasses. We can also create car and truck movie clips in the FLA’s library and associate those symbols with Car and Truck by adding their names as linkage classes in each symbol’s Library Properties dialog. The new symbols will add a visual element to the example because they will be updated by the classes automatically. Because the Vehicle class extends MovieClip, and the x coordinate of Vehicle is updated, any subclass of the Vehicle class will also update its x coordinate.

In this example, we’re going to move away from the timeline and use a document class instead. So start by creating a new ActionScript 3.0 file (ActionScript 3.0 Class file in the New Document window in Flash Professional CS5). We’ll discuss its contents in a moment, but first save the file as Main.as in the same directory as your FLA file, and reference this class, Main, as the FLA’s document class. If you’d rather use the source file provided to get you started, it’s called car_truck.fla.

Lines 1 through 7 create the package, import the necessary class dependencies and create this class. Remember a document class should extend MovieClip so they can behave as a timeline. Lines 9 and 10 create two properties, compact and pickup, and type them as Car and Truck, respectively.

Lines 14 and 20 create instances to these classes, passing in values for gas mileage and fuel available. Both compact and pickup are set to the same initial x value (lines 15 and 21), and pickup is given a different y value (line 22) so you can easily see both vehicles once they are added to the display list (lines 17 and 23).

The custom methods for both instances are called right away (lines 18 and 24), but the vehicles don’t move because the go() method calls are inside an event listener function (lines 38 through 41) waiting for you to click the stage. Setting up the event listeners in lines 26 through 36 is very important, and we’ll discuss this after the code and a description of this example’s output.

1    package {
2
3        import flash.display.MovieClip;
4        import flash.events.Event;
5        import flash.events.MouseEvent;
6
7        public class Main extends MovieClip {
8
9            public var compact:Car;
10           public var pickup:Truck;
11
12           public function Main() {
13
14               compact = new Car(21, 18);
15               compact.x = 0;
16               compact.y = 20;
17               addChild(compact);
18               compact.openSunroof();
19
20               pickup = new Truck(16, 23);
21               pickup.x = 0;
22               pickup.y = 100;
23               addChild(pickup);
24               pickup.lowerTailgate();
25
26               this.addEventListener(Event.ADDED_TO_STAGE,
27                                     onAddedToStage,
28                                     false, 0, true);
29            }
30
31            public function onAddedToStage(evt:Event):void {
32                this.removeEventListener(Event.ADDED_TO_STAGE,
33                                        onAddedToStage)
34                stage.addEventListener(MouseEvent.CLICK, onClick,
35                                      false, 0, true);
36            }
37
38            public function onClick(evt:MouseEvent):void {
39                compact.go();
40                pickup.go();
41            }
42        }
43    }

The first thing to appear in the Output panel when testing your FLA is the initial trace caused by the custom method calls:

[object Car] opened sunroof
[object Truck] lowered tailgate

When the stage is clicked, the go() methods start the car and truck moving, and traces like the one seen in the vehicle-only example will now compare the miles traveled by the car and truck instances. Which will travel the farthest on a tank of gas? The car gets better gas mileage, but has a smaller gas tank. Try it and see!

3    public class Car extends Vehicle {
4
5        public var tires:Tires;
6
7        public function Car(mpg:Number, fuel:Number) {
8            gasMileage = mpg;
9            fuelAvailable = fuel;
10           tires = new Tires("highperformance");
11           trace(this, "has", tires.type, "tires");
12        }

3    public class Truck extends Vehicle {
4
5        public var tires:Tires;
6
7        public function Truck(mpg:Number, fuel:Number) {
8            gasMileage = mpg;
9            fuelAvailable = fuel;
10           tires = new Tires("snow");
11           trace(this, "has", tires.type, "tires");
12        }

This basic Tires class simulates functionality by putting the type of tire requested into a property. In a real-world situation, the new class might affect the performance of a car or truck object. For example, using snow tires might reduce fuel efficiency, and upgrading to high-performance radials might improve mileage. In our simplified example, the Car and Truck classes will just trace the value of this property.

1    package {
2
3        public class Tires {
4
5            public var type:String;
6
7            public function Tires(tire:String) {
8                //simulated functionality change based on tire type
9                switch (tire) {
10                   case "snow" :
11                       type = "storm-ready snow";
12                       break;
13                   case "highperformance" :
14                       type = "high-performance radial";
15                       break;
16                   default :
17                       type = "economical bias-ply";
18                       break;
19               }
20           }
21       }
22    }

As you try out the amended classes, the most important thing to understand is that inheritance is not used to introduce the Tires class. Instead, the car and truck are composed of objects. In this simplified case, only the tires were added, but a complete car (for example) would consist of seats, windows, and so on, all composed rather than inherited from Car or Vehicle. Again, this satisfies the “is a/has a” rule, which should be your guide when deciding whether inheritance or composition is optimal.

No change is required to the document class, but testing the car_truck.fla file again will show a new element to the trace output. In addition to the use of the accessories (sunroof and tailgate) and the resulting miles traveled until fuel is depleted, the tires used will also be traced, as shown:

[object Car] has high-performance radial tires
[object Car] opened sunroof
[object Truck] has storm-ready snow tires
[object Truck] lowered tailgate
[object Car] 21 17
[object Truck] 16 22
[object Car] 42 16
[object Truck] 32 21
...

How, then, can you provide public access to private information? This is accomplished with a special group of methods called getters and setters. These public methods are used to retrieve from, or reassign values to, private properties. In their simplest use, getters and setters can provide a friendly or consistent public name for a possibly more obscurely named property. For example, a property named “registeredUserEmail” could be referenced outside the class as “email.”

Beyond that use case, getters and setters can also add functionality. A simple example includes wanting to allow a programmer to get, but not set, the value of a property. Or, you might want to convert a property value behind the scenes when requested or supplied, without requiring a custom method or two to do so. For instance, a currency value might be stored as a number but, when retrieved with a getter, might be formatted as a string with a leading currency symbol (such as a dollar sign, $), commas, and a decimal point. Neither example is possible when just exposing a property as public.

Getters and setters are also special because they behave like properties as far as the rest of your application is concerned. This simplifies what is typically called an application programming interface (API)—all the public properties and methods of your class (and, by extension, all the classes that make up your application) that a programmer can access.

Let’s revisit our email address discussion to show how this works. The first step in changing from using a public property to using getters and setters is to change the property from public to private. This requires only changing the access modifier, but a common naming convention advocates preceding private properties with underscores. This is a personal choice, and some favor it because you can see at a glance if access to the property is limited to the class. We’ll follow this convention in this book. This first snippet shows both changes:

private var _registeredUserEmail:String = "[email protected]";

Next, to provide access to the property, a getter/setter pair is added to the end of the class. Let’s discuss the content of the functions first. The public getter will return the value of the private property, and the public setter will assign a new value, sent in as an argument, to the private property:

public function get email():String {
    return _registeredUserEmail;
}
public function set email(newEmail:String):void {
    _registeredUserEmail = newEmail;
}

Note, however, that both methods are named “email.” This would ordinarily cause a conflict error because all methods within the same scope must have unique names. However, this is part of how getters and setters work. The matching method names are preceded by identifiers get and set, and both methods work together to appear as a single property in the code that is referencing the class. That is, instead of having to remember and document two functions, perhaps called getUserEmail() and setUserEmail(), all you need is one property: email. Getting and setting are both shown in the following snippet (assuming an example class instance called user):

user.email = "[email protected]";
trace(user.email);

As you can see, property syntax, rather than method syntax, is used. Which version of the method in the class is called is determined by usage. In the first line, a value is being assigned to the property, so the class knows to call the setter. In the second line, no value is assigned, so the class calls the getter, and the property value is retrieved. Now that you have a brief background on implementation, let’s put that information to use in our ongoing vehicle example.

Let’s move to the encapsulation folder of this chapter’s source archive. The first thing we’ll do to adapt our existing code is make the properties in lines 8 through 11 and the method defined in line 20 in the Vehicle class private. All constructors in ActionScript 3.0 must be public, and the go() method should remain public so it can easily be executed from other areas of your project.

1    package {
2
3        import flash.display.MovieClip;
4        import flash.events.Event;
5
6        public class Vehicle extends MovieClip {
7
8            private var _gasMileage:Number;
9            private var _fuelAvailable:Number;
10           private var _milesTraveled:Number = 0;
11           private var _moving:Boolean;
12
13           public function Vehicle(mpg:Number=21, fuel:Number=18.5) {
14               _gasMileage = mpg;
15               _fuelAvailable = fuel;
16               this.addEventListener(Event.ENTER_FRAME, onLoop,
17                                      false, 0, true);
18           }
19
20           private function onLoop(evt:Event):void {
21               if (_moving) {
22                   _fuelAvailable--;
23                   _milesTraveled += _gasMileage;
24                   if (_fuelAvailable < 1) {
25                       this.removeEventListener(Event.ENTER_FRAME,
26                                                onLoop);
27                   }
28                   trace(this, _milesTraveled, _fuelAvailable);
29                   this.x = _milesTraveled;
30               }
31          }
32
33          public function go():void {
34               _moving = true;
35          }

Now that the properties are private, getters and setters must be added to access them. Lines 37 through 55 add a getter and setter pair for each of the private properties in the class.

36            //new getters and setters
37            public function get gasMileage(): Number {
38                return _gasMileage;
39            }
40
41            public function set gasMileage(mpg:Number):
void {
42                _gasMileage = mpg;
43            }
44
45            public function get fuelAvailable():Number {
46                return _fuelAvailable;
47            }
48
49            public function set fuelAvailable(fuel:Number
):void {
50                _fuelAvailable = fuel;
51            }
52
53            public function get milesTraveled():Number {
54                return _milesTraveled;
55            }
56        }
57    }

Getters and setters are used to update properties, but subclasses can also update properties of a superclass directly. Remember that when Car and Truck instances were created, the constructor of these subclasses updated the gasMileage and fuelAvailable properties of Vehicle class. If those properties are no longer public, this isn’t possible using the same techniques.

A subclass uses the super() method to call the corresponding method in its superclass. For example, placing super() in a subclass constructor will call the constructor in the superclass. You can even pass arguments into the superclass method, if the superclass constructor normally accepts the same arguments. We will modify the Car and Truck classes to use this technique.

When building instances of these classes, you can pass arguments in to create custom miles per gallon and available fuel values for each car or truck. Because the classes inherit properties from Vehicle, these properties are not recreated. However, now that we’re exploring encapsulation, and the properties are private, a direct assignment is not possible. Instead, you can use the syntax super() to pass the incoming values on to Vehicle where the properties are assigned. The object super refers to the superclass, and the super() statement explicitly calls the constructor of the superclass. Line 8 in both of the following excerpts uses this technique.

Also note that, just like in the Vehicle class, we’ve changed the property from public to private (line 5 in both Car and Truck classes), and added an underscore to the start of the property name (line 5, and again when used in lines 9 and 10, of both classes).

3    public class Car extends Vehicle {
4
5        private var _tires:Tires;
6
7        public function Car(mpg:Number, fuel:Number) {
8            super(mpg, fuel);
9            _tires = new Tires("highperformance");
10           trace(this, "has", _tires.type, "tires");
11       }

3    public class Truck extends Vehicle {
4
5        private var _tires:Tires;
6
7        public function Truck(mpg:Number, fuel:Number) {
8            super(mpg, fuel);
9            _tires = new Tires("snow");
10           trace(this, "has", _tires.type, "tires");
s11       }

The Tires class (Tires.as) is adjusted in much the same way the Vehicle class was altered, shown in the bold lines that follow. First, the lone property becomes private, and its uses are updated to add the underscore reserved for private properties. Next, a getter and setter pair is added to make the property accessible outside the class.

1    package {
2
3        public class Tires {
4
5            private var _type:String;
6
7            public function Tires(tire:String) {
8                //simulated functionality change based on tire type
9                switch (tire) {
10                   case "snow" :
11                       _type = "storm-ready snow";
12                       break;
13                   case "highperformance" :
14                       _type = "high-performance radial";
15                       break;
16                   default :
17                       _type = "economical bias-ply";
18            }
19        }
20
21        public function get type():String {
22            return _type;
23        }
24
25        public function set type(tire:String):void {
26            _type = tire;
27        }
28        }
29    }

The only changes required to the document class to complete our encapsulation example are to make the properties and methods private, and add an underscore to the property names. Only the class and constructor remain public. Note these changes in bold:

7    public class Main extends MovieClip {
8
9        public var _compact:Car;
10       public var _pickup:Truck;
11
12       public function Main() {
13
14           _compact = new Car(21, 18);
15           _compact.x = 0;
16           _compact.y= 20;
17           addChild(_compact);
18           _compact.openSunroof();
19
20           _pickup = new Truck(16, 23);
21           _pickup.x = 0;
22           _pickup.y = 100;
23           addChild(_pickup);
24           _pickup.lowerTailgate();
25
26           this.addEventListener(Event.ADDED_TO_STAGE,
27                           onAddedToStage,
28                           false, 0, true);
29        }

The property names also appear in the onClick() method.

30        private function onClick(evt:MouseEvent):void {
31            _compact.go();
32            _pickup.go();
33        }
34

Employing polymorphism with inheritance allows you to design subclasses that can use the same method names as their superclasses, but without creating a conflict. For example, a superclass can have a public method called “turn,” which multiple subclasses use. One subclass, however, might also have a public method called “turn,” that is either entirely different or enhanced. Ordinarily, the fact that a subclass inherits public methods from a superclass means that the subclass would effectively have two methods called “turn” and a conflict would exist.

However, polymorphism allows the subclass method to replace or augment the superclass method of the same name by overriding it. Overriding a method tells the compiler that the new version of the method (in the subclass) takes precedence over the previous version of the method (in the superclass).

To demonstrate this process, let’s begin by adding two methods to our Vehicle class. If you want to look at the source files, they are in the polymorphism folder of the chapter archive. The new methods can be seen in lines 33 through 39 in the following excerpt, and are named useAccessory() and changeGear(). Both of the new methods are available to the Car and Truck subclasses through inheritance and notice that the functionality of the useAccessory() method is to turn on a vehicle’s lights.

20    private function onLoop(evt:Event):void {
21        if (_moving) {
22        _fuelAvailable--;
23        _milesTraveled += _gasMileage;
24        if (_fuelAvailable < 1) {
25            this.removeEventListener(Event.ENTER_FRAME,
26                             onLoop, false, 0, true);
27           }
28           trace(this, _milesTraveled, _fuelAvailable);
29           this.x = _milesTraveled;
30           }
31        }
32
33        public function changeGear(): void {
34            trace(this, "changed gear");
35            }
36
37            public function useAccessory():void {
38                trace(this, "vehicle lights turned on");
39            }

Next let’s see how to override the useAccessory() method in the Car and Truck classes so we can customize its functionality without having to change our API.

A public method also named useAccessory() is added to the Car class, seen in lines 17 through 19 of the following excerpt. Remember that this would ordinarily conflict with the method of the same name in the Vehicle superclass, because of inheritance. As discussed previously, we avoid this by preceding the method declaration, including its access control modifier, with the override keyword.

The functionality of the method is the same in both classes: to use an accessory. So the useAccessory() method in the Car class can call its existing openSunroof() method.

13    public function openSunroof():void {
14       trace(this, "opened sunroof");
15    }
16
17    override public function useAccessory():void {
18        openSunroof();
19    }

The beauty of this arrangement is that you’ve created an API that employs the flexible “use accessory” idea to . . . er . . . use accessories. Hereafter, you can write instancename.useAccessory() and be free to change your Car class without having to change the rest of your application. For example, you might have many method calls using the syntax useAccessory() that all open car sunroofs. If you later decide to change the accessory to something else, you would need to edit only the Car class, not the many existing method calls, to update your application.

Now we’ll do the same thing with the Truck class, but with a twist. In some cases when overriding, you may not want to entirely replace the original behavior that exists in the superclass. When needed, you can execute the custom code in the subclass method and call the same method in the superclass. To do this, add an instruction in the subclass method to explicitly call the original superclass method, as seen in line 18 of the Truck class. In this case, you can’t simply use the super() statement the way you did earlier, because that only works in the constructor. Within a method, you must reference the superclass using the super object, and follow it with the superclass method you want to call. The edit is in bold.

13    public function lowerTailgate():void {
14        trace(this, "lowered tailgate");
15    }
16
17    override public function useAccessory():void {
18        super.useAccessory();
19        lowerTailgate();
20    }

No change to the Tires class is required, but we’ll make two changes to the document class Main to show the outcome of your efforts. First, in both Car and Truck instances (compact and pickup), we’ll call the other method we added, changeGear() (lines 18 and 25). This will show that the outcome of a public method called from either car or truck will be the same if polymorphism is not in play.

Next, we’ll follow the example discussed and change our code from calling openSunroof() and lowerTailgate(), for compact and pickup respectively, to both instances calling useAccessory() (lines 19 and 26). This will make our code a bit more flexible, as we can later change the accessories in one or both classes and not have to change our FLA to benefit from the adjustment.

12    public function Main() {
13
14        compact = new Car(21, 18);
15        compact.x = 20;
16        compact.y = 20;
17        addChild(compact);
18        compact.changeGear();
19        compact.useAccessory();
20
21        pickup = new Truck(16, 23);
22        pickup.x = 20;
23        pickup.y = 100;
24        addChild(pickup);
25        pickup.changeGear();
26        pickup.useAccessory();
27
28        this.addEventListener(Event.ADDED_TO_STAGE,
29                              onAddedToStage,
30                              false, 0, true);
31    }

An abbreviated output follows. As you can see, the car class traced its tires, the compact instance changed gear, and then used its accessory. This opened the sunroof, but nothing more because the Car class override replaced the functionality of the Vehicle useAccessory() method, which turned on the vehicle’s lights. The pickup behaved similarly, but in addition to lowering its tailgate, also turned on its lights. This is because the Truck class also called the useAccessory() method in the superclass, rather than just overriding it.

[object Car] has high-performance radial tires
[object Car] changed gear
[object Car] opened sunroof
[object Truck] has storm-ready snow tires
[object Truck] changed gear
[object Truck] lowered tailgate
[object Truck] turned on lights
[object Car] 21 17
[object Truck] 16 22
[object Car] 42 16
[object Truck] 32 21
...

Earlier, we said there’s another way to use polymorphism that doesn’t focus on inheritance. Because it’s not based on method overriding between subclass and superclass, it’s applicable to more situations. The general idea is the same, in that your coding is simplified by using the same method names across different object types. However, it’s even more useful in that it adds additional flexibility by not requiring that you type your object to a specific class.

To help explain this, let’s sideline a bit to revisit two important ActionScript 3.0 topics: compile-time error checking and the display list. The benefit of using data typing with your objects is that the ActionScript compiler will warn you if you do something that’s incompatible with your stated data type. By design, the simplest case means that you can only work with one data type. (A look at Chapter 2 will reinforce this idea if you need a quick review.)

However, there are times when you may want things to be a bit more flexible. For example, you may want to put either a MovieClip or Sprite into a variable. If you type the variable as MovieClip, only a movie clip will be accepted. To get around this, you can type a variable as the base class DisplayObject, from which both MovieClip and Sprite descend (see Chapter 4 for more information), and the compiler won’t object.

The downside to this is that it can be a bit too generic. If, for example, you used a movie clip method on an object that the compiler only understood as a DisplayObject, an error would occur:

var thing:DisplayObject = new MovieClip();
thing.play();

Why? Because, although play() is a legal movie clip method, the compiler doesn’t understand that thing is actually a movie clip. It might be a sprite (and that flexibility is the very reason we’re discussing this), and a sprite doesn’t have a timeline.

This can be addressed by casting (also discussed in Chapter 4), but that kind of defeats the purpose of what we’re doing. Instead, what if you could specify a data type that was flexible enough to work with different kinds of objects, but also knew which methods those objects supported? That’s where interfaces come in.

As we explained earlier, an interface is simply a list of public methods that must be present in a class. The following is an example of an interface that might be used with classes for devices that play music (like a radio or CD player). All of the code for this discussion can be found in the polymorphism_interface source code directory. The interface is called IAudible and is found in the IAudible.as source file. It’s a very common practice to start the name of all interfaces with a capital I, to differentiate them from classes.

1    package {
2
3       public interface IAudible {
4
5           function turnOn():void;
6           function playSelection(preset:int):void;
7           function turnOff():void;
8
9       }
10    }

As you can see, not even the content of a method is included. Only the name, parameters and data types, and return data type (which are collectively called the method’s signature) are included. Also, any import statements needed to support included data types are required. (In this case, the compiler automatically understands the int data type. However, if a data type represents a class, such as MovieClip or Event, that class must be imported.)

Once you’ve created an interface, you can require a class to adhere to it by implementing it using the implements keyword in the interface declaration, as shown in line 3 of the following simple Radio class (Radio.as):

1    package {
2
3        public class Radio implements IAudible {
4
5            public function Radio() {
6                trace("radio added");
7            }
8
9            public function turnOn():void {
10               trace("radio on");
11           }
12
13           public function playSelection(preset:int):void {
14               trace("radio selection: channel", preset);
15           }
16
17           public function turnOff():void {
18               trace("radio off");
19           }
20        }
21    }

All this class does is trace appropriate diagnostic statements, identifying itself as “radio” each time. It complies with the interface because every method required is present. Here is a CDPlayer class (CDPlayer.as) that also implements, and complies with, the same interface. The purpose of the class is similar, but it identifies itself as “cd player” in each trace to demonstrate unique functionality.

1    package {
2
3        public class CDPlayer implements IAudible {
4
5            public function CDPlayer() {
6                trace("cd player added");
7            }
8
9            public function turnOn():void {
10               trace("cd player on");
11           }
12
13           public function playSelection(preset:int):void {
14               trace("cd player selection: track", preset);
15           }
16
17           public function turnOff():void {
18               trace("cd player off");
19           }
20
21           public function eject():void {
22               trace("cd player eject");
23           }
24
25        }
26    }

Although the Radio and CDPlayer classes do different things (demonstrated simply by the unique traces), the method names required by the interface are present in both classes. This means that you can write a full application using a radio, later swap out the radio with a CD player, but not have to change any of your basic method calls—a key benefit of polymorphism. The CDPlayer class also demonstrates that additional methods, not referenced by an interface, can appear in classes—as shown by the eject() method in lines 21 through 23. An interface is only designed to enforce a contract with a class, making sure the required methods are present. It doesn’t restrict the functionality of a class.

All that remains is putting this into practice. The following basic implementation is found in the sound_system.fla source file. The key step in using interfaces in this context is typing to the interface. If you type to Radio, you can’t switch to CDPlayer later. However, if you type to IAudible, the compiler will nod approvingly at both Radio and CDPlayer. Also, because the interface rigidly enforces that all public methods are present, you don’t run into situations where the compiler is unsure if a method is legal. This is polymorphism at its best. The following script starts with a radio and then switches to a CD player, using methods in both cases without error.

var soundSystem:IAudible = new Radio();
soundSystem.turnOn();

soundSystem = new CDPlayer();
soundSystem.turnOn();
soundSystem.playSelection(1);

Now let’s practice what you’ve learned by composing the sound system example into the ongoing vehicle exercise. This will review encapsulation, composition, and polymorphism.

First, add another private property to the Vehicle class to hold the sound system, just like we did when we composed Tires into the exercise. It’s typed to the interface to allow a vehicle to have any sound system that implements IAudible. The property can be seen in line 12 of the following excerpt from the Vehicle.as source file:

8        private var _gasMileage:Number;
9          private var _fuelAvailable:Number;
10         private var _milesTraveled:Number = 0;
11         private var _moving:Boolean;
12         private var _soundSystem:IAudible;

Next, provide public access to this property by adding a getter and setter, again typed to the IAudible interface. The following excerpt, still in the Vehicle.as source file, shows this addition in lines 64 through 70:

60    public function get milesTraveled():Number {
61        return _milesTraveled;
62    }
63
64    public function get soundSystem():IAudible {
65        return _soundSystem;
66    }
67
68    public function set soundSystem(device:IAudible):void {
69        _soundSystem = device;
70    }

The last class changes involve adding an instance of CDPlayer in the Car class, and a Radio instance in the Truck class—just as we did when adding Tires in the composition example. This excerpt from the Car class (Car.as) shows the change at the end of the constructor:

7    public function Car(mpg:Number, fuel:Number) {
8        super(mpg, fuel);
9        _tires = new Tires("highperformance");
10       trace(this,       "has", _tires.type, "tires");
11       soundSystem = new CDPlayer();
12   }

This excerpt from the Truck class (Truck.as) also adds the sound system at the end of the constructor. The edits in both classes appear in bold at line 11:

7    public function Truck(mpg:Number, fuel:Number) {
8         super(mpg, fuel);
9         _tires = new Tires("snow");
10         trace(this, "has", _tires.type, "tires");
11       soundSystem = new Radio();
12   }

Finally, the document class is modified to use the sound system in both the Car instance (compact) and Truck instance (pickup) when you click the stage. Shown in bold in the Main.as excerpt below, lines 42 through 44 access the CD player and radio through the soundSystem property. This triggers the getter method in the respective classes and returns the car’s CD player and the truck’s radio.

39    public function onClick(evt:MouseEvent):void {
40        compact.go();
41        pickup.go();
42        compact.soundSystem.turnOn();
43        compact.soundSystem.playSelection(2);
44        pickup.soundSystem.turnOn();
45    }

The trace immediately reflects the fact that the car has a CD player and the truck has a radio. Once you click the stage (shown by the gap in the output that follows), the sound systems are used and the vehicles drive off into the sunset.

[object Car] has high-performance radial tires
cd player added
[object Car] changed gear
[object Car] opened sunroof
[object Truck] has storm-ready snow tires
radio added
[object Truck] changed gear
[object Truck] lowered tailgate
[object Truck] turned on lights
cd player on
cd player selection: track 2
radio on
[object Car] 21 17
[object Truck] 16 22
...

The entry point to this project is the document class, LAS3Main.as, which follows. Lines 3 and 4 import the MovieClip class and custom NavigationBar class, which you’ll create in a moment. Line 6 declares the class and extends MovieClip. Lines 8 through 14 contain the class constructor.

This navigation bar can feature a variable number of buttons, determined by the contents of an array seen in lines 9 and 10. Lines 11 and 12 creates an instance of the NavigationBar class and passes in the array of labels for the new buttons. Finally, line 13 adds the navigation bar to the display list.

1    package {
2
3         import flash.display.MovieClip;
4        import com.learningactionscript3.gui.NavigationBar;
5
6        public class LAS3Main extends MovieClip {
7
8            public function LAS3Main() {
9                var menuData:Array = ["one", "two", "three",
10                       "four", "five"];
11               var navBar:NavigationBar =
12                   new NavigationBar(menuData);
13               addChild(navBar);
14           }
15       }
16    }

Next we need to create the NavigationBar class (NavigationBar.as), which will be the home for our buttons. Here we’ll focus on the times that are appreciably different in purpose from the prior class, or are otherwise noteworthy. Line 1, for example is the package declaration discussed several times previously in the book, but is worthy of mention because it reflects the location of the class—in the gui directory, within the com directory, found in the same folder as the FLA. Lines 9 through 12 contain the class constructor, populate the properties with the incoming argument data, and call the build() method:

1    package com.learningactionscript3.gui {
2
3        import flash.display.MovieClip;
4
5        public class NavigationBar extends MovieClip {
6
7            private var _navData:Array;
8
9            public function NavigationBar(navData:Array) {
10               _navData = navData;
11               build();
12           }

In the next code segment, the build() method uses a for loop to add each button to the navigation bar. The loop first creates an instance of the MenuButtonMain class, passing the name of the button as a string for the button’s label. This string comes from the button array passed into the constructor from the document class, and can be seen in line 9 of the prior class. Next, the button is positioned horizontally by starting with a 20-pixel offset, and then multiplying the width of the button plus a 2-pixel space for each button. That is, the first button starts at 20 pixels because i begins as 0 and no further offset is added. The second button starts at 20 and then 1 * (button width + 2) is added, and so on. A fixed y location is also used, and each button is added to the display list.

Finally, the aforementioned horizontal bar from the FLA library is added to the bottom of the menu buttons (lines 22 through 25). Two things are important here. First, the line is typed as MovieClip to give you a bit more flexibility. We haven’t yet created a dedicated class for this object, and it’s a movie clip in the FLA. Second, as a display object, this line movie clip can be a target of mouse events. Because it has no active role in the navigation bar, we disable it from interacting with the mouse by setting its mouseEnabled property to false.

13          private function build():void {
14              for (var i:uint; i < _navData.length; i++) {
15                  var menuBtn:MenuButtonMain =
16                      new MenuButtonMain(_navData[i]);
17                  menuBtn.x = 20 + i * (menuBtn.width + 2);
18                  menuBtn.y = 75;
19                  addChild(menuBtn);
20              }
21
22              var hline:MovieClip = new HLineThick();
23               hline.y = 100;
24               hline.mouseEnabled = false;
25               addChild(hline);
26           }
27       }
28   }

Finally, we present the MenuButtonMain class, which creates the button for each menu added to the navigation bar. In addition to the previously explained package declaration and imports, this class also uses two text classes originally discussed in Chapter 4—the display list class TextField and the text automatic sizing and alignment class, TextFieldAutoSize. The text field goes into a private property called _btnLabel, and the remainder of the functionality will be explained after the code.

1    package com.learningactionscript3.gui {
2
3        import flash.display.MovieClip;
4        import flash.events.MouseEvent;
5        import flash.text.TextField;
6        import flash.text.TextFieldAutoSize;
7
8        public class MenuButtonMain extends MovieClip {
9
10       private var _btnLabel:TextField;
11
12       public function MenuButtonMain(labl:String) {
13               _btnLabel = new TextField();
14               _btnLabel.autoSize = TextFieldAutoSize.CENTER;
15               _btnLabel.textColor = 0xFFFFFF;
16               _btnLabel.text = labl;
17               _btnLabel.mouseEnabled = false;
18               addChild(_btnLabel);
19
20               buttonMode = true;
21               useHandCursor = true;
22               addEventListener(MouseEvent.CLICK, onClick,
23                           false, 0, true);
24           }
25
26           private function onClick(evt:MouseEvent):void {
27               trace(_btnLabel.text);
28           }
29       }
30    }

Lines 13 through 18 apply to the text label inside the button. When a button is created, a string that will serve as the button text is passed into the labl parameter (custom-named to differentiate it from an ActionScript property called label). Line 13 creates a new text field and line 14 sizes the field to the minimum dimensions required to display the text—reducing the field at left, right, and bottom, effectively centering the text. Line 15 colors all text in the field white, and line 16 places the string from labl into the field.

Line 17 is particularly important in this example. The default mouse behavior for a dynamic text field is to display a standard I-beam text cursor and allow a varying degree of text editing (depending on properties we’ll discuss in Chapter 10). As such, a text field used inside a button will follow this behavior and intercept mouse events, preventing the button from behaving properly. Line 17 disables mouse interaction with the text field, so it won’t interfere, and so the mouse will display a pointer cursor when interacting with the button. Line 18 adds the field to the button.

Lines 20 through 23 apply to the button itself. Although a movie clip will react to mouse events, it will not exhibit the mouse cursor feedback associated with a button. For example, it won’t switch from a pointer to a finger. Line 20 tells the movie clip to behave like a button, and line 21 enables the button mouse cursor. Lines 22 and 23 assigns a mouse click listener to the button.

For simplicity, this exercise merely traces the text of each button clicked to the Output panel. Later in the book, we’ll show you how to format text and load external assets using the next generation of this navigation bar. Figure 6-4 shows the final navigation bar.

Figure 6-4. The finished navigation bar