One of the most important things to understand when building large-scale, expandable Flash projects is Object Oriented Programming, or OOP for short. According to Wikipedia:
Object-Oriented Programming (OOP) is a programming paradigm that uses “objects” – data structures consisting of datafields and methods together with their interactions – to design applications and computer programs.
Basically, its a style of programming, that makes things much easier! I’m sure you’ve seen projects that had hundreds, if not thousands of lines of actionscript written to make all the magic happen. If the original programmer didn’t use an “OOP style” of programming, you would probably have to spend a good few hours just trying to figure out what the program does, let alone change anything and not cause more bugs in the process! This type of programming is sometimes refereed to as “Spaghetti Code” because you have to follow long twisty noodle-like paths to get around.
A more effective way to program is to take the Object Oriented approach. You organize every different piece of the program into different Classes.
An Object is a collection of attributes & behaviors encapsulated into a one small entity. The attributes are all of the variables. For example, if we were creating a BabyBoy() Object, some attributes we may have are eyeColor, height, weight, age, etc. These variables hold all of the data that is contained within the BabyBoy() Object. Some behaviors we might find are eat(food:FoodObject), sleep(duration:Number), dance(bpm:Number).
If the behaviors (methods) I just showed you don’t make any sense, you should read up on Actionscript Functions.
So now that you know what an Object is, you need to understand how Instances work. When you have an object class, you don’t actually reference the class, you create an instance of it. For example:
var myObjectInstance:Object = new Object();
// Then we adjust the attributes (variables) & run
// the behaviors (methods) on that instance.
myObjectInstance.myVariable = "New Variable Value";
myObjectInstance.myMethod();
Classes are blueprints of an Object. They organize all of the variables & methods that each Object can use. A basic BabyBoy() Class would look like this:
package com {
// import the class we are going to extend
// (More on this soon)
import flash.display.Sprite;
// import the custom classes we use
import com.food.FoodObject;
public class BabyBoy extends Sprite {
private var eyeColor:uint = 0xFF0000;
private var heightInInches:Number = 13;
private var weightInPounds:Number = 12;
private var ageInDays:Number = 4;
public function BabyBoy() {
// Constructor functionality
}
public function eat(_food:FoodObject):void {
// Eat functionality
}
public function sleep(_duration:Number):void {
// Sleep functionality
}
public function dance(_bpm:Number):void {
// Dance functionality
}
}
}
As you can see, everything that you want an instance of the BabyBoy class to be able to do, has to be built into the Class. Let’s go through the class one section at a time.
First off, at the top, we declare where the actual class is located: package com { is actually saying “this package lives inside of a folder called com”. So next to your FLA & Actionscript file, there would be a folder named com. This is where you organize and hold all of your Class files. You want to keep it as organized as possible.
Next we import all of the Classes we are going to use in this particular Class. We then declare the Class, extending the Sprite Object:
public class BabyBoy extends Sprite {
The name BabyBoy must match exactly the file name (minus the .as) and the first function (constructor) name.
After the class name, you declare the variables you are going to be using. If you use private before the var, the variable is only accessible from within this class. You will not be able to access it from another place. However, if you needed to access it from outside of this Object, you could change the private to be public. Now you can access the variable from anywhere, just target the class instance then the variable:
myClassInstance.myVariable = "new variable value";
trace(myClassInstance.myVariable);
// displays "new variable value"
Next up is the constructor function. The name of the constructor must match the file name (minus the .as) and the Class name. This method executes when an instance of the class is created. You want to use this function to call other functions that set up the object, or do any procedures you need to make the Objects functionality work.
Finally we have the rest of the public & private methods/functions. These are the brains of the Object. You call on these to make the Object work.
Let’s take a sec and do a visual re-cap:

Let’s say for a particular project, you would be needing classes for BabyBoy, BabyGirl, YoungBoy, YoungGirl, OldMan and OldWoman. You would probably want to have a folder (package) inside of the com folder called “people”. Inside of people, you would put all of your classes.
If you needed to add another class or two for Dog() & Cat() Objects, you would create another folder inside of com called “animals”. This keeps all of your classes organized into thought-out structures. It’s easier to locate the class you need when your package structure is well designed.
In the BabyBoy() Class example, we are extending the Sprite() Object. This is called Inheritance. Just as when you inherit money from a rich relative, when you extend an Object, you inherit all of its variables & methods. Sometimes you can start out with a fresh class, and have no need to inherit the characteristics of another Object. However, sometimes it would save you tons of time to extend a Sprite() Object instead of going from scratch. You get dispatchEvent() for sending out Events, addChild() for placing DisplayObject’s into the Object, and so forth.
When starting to write a new class, you should think about what your class is going to need to do, and see if there is already a class written that has some or all of that functionality built in. If you find one, go ahead and extend it for your new creation, and add the custom parts that were not inherited.
Encapsulation is an important part of OOP, which pretty much means hiding the details of how an Object does what it does. You expose an Interface to use the Object, which is made up of the public methods in the Class.
A good way to imagine Encapsulation is to think of a computer. You don’t need to know exactly what is going on after you hit the power button, you just need to know that pushing that button turns the computer on. You also don’t need to know how the keyboard sends the letters to your screen, you just need to know it does.
So you build a good collection of public methods that cover all of the stuff you’re going to have to use to actually use the Object, and the rest of the functionality is broken up into small private methods that do individual tasks.
That covers the basics of Object Oriented Programming. If you still can’t wrap your head around the ideas, don’t worry, sometimes it takes a few times to sink all in. If you have a specific question, just leave a comment, and I will try to answer everything & revise the article to explain it a bit more clearly.
I would also suggest taking a look at some of these resources: