Tutorial: the basics of object-oriented programming in ActionScript 1, 2 & 3

[ Download the presentation slides ]

A long time ago, I put together a crash course on object-oriented programming in ActionScript. I'm still receiving positive feedback about it now, so I decided to put it online.

It's a learn-by-example tutorial about OOP in Flash. The primary goal I had in mind when making this tutorial was to teach the basics of OOP to Flash designers in a couple of hours. Well, I explained the theory in a few hours and I gave everybody ActionScript files with a focused example of every part that I explained. And some say this worked .

For optimal understanding of this very condensed tutorial, it's best that you know how to use Flash and that you know what ActionScript in Flash is good for. You need Adobe Flash CS3 to open and compile the .fla files.

Very schematically, the course outline:

• The "object"
• Welcome to the class
• Inheritance and polymorphism
• Composition
• Class Interface
• Exception handling
• Event handling and dispatching

Wherever possible, I made the same example for every version of ActionScript (from 1 to 3). So, you can easily compare the different versions and check out how old school cool the AS1 prototype looks. I've added inline instructions and explanations by means of comments in the code.

The "object"

What is an object? Everything can be described in an object via data abstraction: with properties and methods. Think of a bike, for instance. A bike is a vehicle. Every conventional bike has basic structural properties like a frame, 2 wheels, a saddle, 2 pedals, a chain, steering, etc. The main function of the bike is to ride. Via the bike's bell you can make a ringing sound. Instance properties of the bike are its size, its color, ... Whether a bike is red or blue changes nothing about the structure of the bike, the color is only a changeable property. Structurally identical bicycles can exist in many different colors. The red and the blue bike are 2 instances of a bike that was built by the same mold or blueprint.

For the fun of it, just try to make this kind of data abstraction for other objects (both physical and non-physical) by identifying the objects' properties and functions that seem relevant (ex. try to describe a Cat).

The definition of the structure of an object is what is called a class. An object is a specific instance of a class. In object-oriented programming, a system or program is constructed by means of objects.

Welcome to the class

Programming involves syntax. One of the first things I think you should know to start programming OO, is how to write a class (or prototype). A class is often described as a blueprint. Download 01_Class.zip and see how to write a class / prototype in ActionScript 1, 2 & 3. Take a good look at the constructor, i.e. the place where we can say that an instance of a class is being constructed. Every class has a constructor. If you happen not to write one, then an empty constructor is added automatically.

Geeks (like myself) should also check out the similarities between ActionScript 1 and JavaScript. They're alike because both languages are ECMAScript dialects.

Inheritance and polymorphism

Inheritance is the mechanism where a class inherits the properties and the methods of a hierarchically higher class. By inheriting properties and methods from another class you create a hierarchical classification. Inheritance also makes it possible to create variations of base classes.

In this context, think for example about the hierarchy of vehicle > bike, or: mamals > apes > humans. Download 02_Inheritance.zip and check out the example where we extend the MovieClip (read inherit all properties and methods from the MovieClip class) and create a specific kind of MovieClip that automatically bounces around on the stage.

Directly related to inheritance are the benefits of polymorphism: the ability of objects belonging to different classes to respond to operations of the same name, each one according to the right class-specific behaviour. Say what? Oh well, check out the example in the same zip.

Inheritance can improve reusability of code and makes it possible to centralize logic. However, badly constructed class hierarchies (which happens very often when the goal of a system isn't defined clearly on beforehand) can lead to unmanageable systems. Manageability can be improved by applying composition, because composition enables switching between different implementations.

Composition

Some say to always favor composition over inheritance. If you just need services from another class, use composition. If your class behaves very much like an existing class: consider inheritance (but choose composition ). If you need the advantages of polymorphism: use inheritance. In ActionScript you can only inherit from one class at a time, so that's an extra reason to favor composition over inheritance. Download 03_Composition.zip and see the alternative for the previous example where we extended the MovieClip. The class BounceAroundComposition "HAS-A" MovieClip that's bouncing around on the stage, whereas the class BounceAround from our previous sample "IS-A" MovieClip.

Class Interface

An interface is often described as a "contract" for a class implementing it. Basically, it's a definition of the methods that minimally need to be implemented. Using interfaces can lead to more flexible code when using interfaces "as-if" they're the datatype: this way, you can switch between implementations with minimal effort. The class interface was first introduced in ActionScript 2. Download 04_Interface.zip to see a dummy sample.

Exception handling

Errors abort code execution and that's a good thing because errors must always be exposed (also read this post about dealing with runtime errors).
Code in which something can possibly go wrong should be wrapped in a try-catch block. Please note that the finally-block always executes. Errors bubble up the stack, up to the stage (where the plugin catches them).
Don't hesitate to throw your own errors in your code when execution is better to be aborted because of certain conditions in your program. It's very often a good idea to subclass the Error with specific types of Errors, such as IllegalArgumentError, OutOfBoundsError, or WhateverError. The more information, the easier it becomes to track and correct bugs. Download 05_Exceptions.zip to look at the silly example I created.

Event handling and event dispatching

Events determine flow. Events orginate from user actions such as key presses, mouse gestures or messages sent out by objects, the system, etc. An instantiated event first get processed by an event dispatcher and then the event is being associated with event handlers of interested objects. Event-driven programming is a good way to accomplish loose coupling between different encapsulated parts or components.

Download 06_EventHandling.zip to check out the sample about handling component events (good ol' v1, bad ass v2 & smooth v3 components). And also download 07_EventDispatching.zip to find out how you can dispatch custom events (and handle them off). Subclassing the Event is elegant, always consider it.

It's good to have notion of the event flow of an event object like for example the mouse click event that moves through the display list. A mouse click first goes from the stage down to the target component (capture phase) and then the click event starts bubbling back up to the stage (bubble phase). Read more about it here.

So what's next?

If you're serious about becoming a good programmer (in any language), I would advise you to learn about object-oriented design (OOD). There are great books explaining how to structure your code in order to solve common problems. Many of these books are inspired by the book Design Patterns: Elements of Reusable Object-Oriented Software (written by the Gang of Four). Probably the biggest challenge in programming is learning to write code that's reusable, encapsulated, maintainable, flexible and scalable. Becoming a good programmer is a continuous growing process that's being fed by project experience, expert advice and study.

There are at least 2 widely accepted development frameworks that I think you should check out when you're serious about developing "rich internet applications": Cairngorm (for Flex) and PureMVC (for both Flash and Flex).

Any kind of feedback/tips to help me improve this blog post is welcome, so don't hesitate to drop me a line via e-email: hans{ at }novio.be.

Thanks to my colleague Vincent Vanderheeren for reviewing this blog post and giving me useful tips.