Chapter 9: Object-Oriented Programming with as 2.0

It's now time for the often-mentioned chapter on Object-Oriented Programming (OOP). Up until now, we've predominantly been using the ActionScript 1.0 syntax. For the most part, ActionScript 1.0 (AS1) and ActionScript 2.0 (AS2) are the same. The major changes in ActionScript 2.0 have to do with how we code OOP. For this reason, this chapter will also serve as an introduction to AS2.

We are going to start by covering the foundation of OOP. We'll talk about some key concepts such as classes, inheritance, polymorphism, data hiding, and interfaces. Along the way, we'll look at examples of each in action through Flash. Because there are so many diverse concepts going on in this tightly packed chapter, I've chosen to demonstrate these through individual examples. In the next chapter, we will start to build on these ideas back within the environment of game development.

What Is OOP?

OOP is a style of programming that promotes organization in code by making elements of a program elegant and easily maintainable by dividing the program into modular pieces. Inside each module or object, you don't necessarily need to know exactly what is going on; you can make the assumption that it does what it is supposed to do while remaining self-contained.

Think of an electric car and a gasoline- powered car. The engines work on extremely different principles, but in most ways, they are functionally interchangeable. Each engine has some connection to the accelerator and some way of producing the power needed to move the car. In this case, the concept of an engine has some well-defined requirements as well as some common interfaces.

In the cases of the cars , we can make two important assumptions. First, pressing the accelerator in each has the same end result. This means that we have a common input and output. As long as the elements that make up what it means to be an engine are satisfied, we can assume that the job will get done.

The second assumption is a little bit out of left field. We can assume that the CD player isn't going to be conditional based on which engine is in the car. Although in the end, the majority of the cars' systems are related in many ways, they are related through clear, mapped out paths. Our engine isn't going to check to see if the CD player is on track 1 before performing some operation.

This might seem absurd, but when we take this back to a programming environment, it doesn't seen nearly as strange to look for a specific property of a specific movie clip of a game to make a logic decision. In OOP, the idea is that you should be able to place your object in another program and have it function as needed without relying on many far-flung functions and variables that might not be available in this movie.

Our first step in looking at OOP is going to be making some of these definitions. What generic types of objects do we need to make our program work? Do we need an engine? Do we need a spaceship? Or do we need something even more generic, such as a common bad guy? In the next section, we'll make some plans and start writing some code.

Planning

To have modular objects, you have to decide at the beginning what modules need to exist and how they need to interact with the rest of the program. This decision on all the communications and functionality results from a diligent planning phase. Even though it is tempting ”in Flash especially ”to sit down and start drawing and coding, you will almost always fail to think of some cases that need to be taken into account while programming on-the-fly . It's always the last-minute fixes on a program that can turn an elegant modular script into a morass of twisted intertwined code that becomes a nightmare to decipher later. The only real solution is to map out the modules before writing the first line.

Now that I've made this sound strict and tedious , I will say that depending on the scale of the program I'm doing, some planning phases have been brief. There are three major factors for determining how much planning should occur at the beginning of a project:

• The complexity of the project

• The number of people working on the project

• The desire to reuse the code

If a project is complex, as most games are, mapping out the flow of the game is always a good idea. Some simple flowcharts or a state machine can also save you time by forcing you to think of all the paths through which the logic of a game will have to flow. Not all games are wildly complex, though. You have to use your best judgment. My rule of thumb is that if I can't write all the code in one sitting, it is probably more complex than I can keep in my head from one coding session to another.

OOP is an excellent style if you want to divide the coding work. The modularity just described allows you to parcel out each of the objects after a discussion of all the common points where other parts of the object need to be exposed to the other objects that make up the rest of the application. Having a firm plan in place frees the individual developers to concentrate on their particular code without being required to know all the details of the big picture.

The last consideration about reusing code is really a sign of laziness . (Well, I like to think of it as practicality.) If I am working on a simple project by myself and don't care if I ever see the code again, I don't worry about the planning stages. I really don't even care about good programming style. I just work as fast as I can to get on to other projects.

However, if I am writing code that I will use again, I spend the extra time to write the code in a way that is well thought-out and generic enough to work in a broad range of environments. The extra time spent upfront saves me time later when I want to reuse the code.

Let's leave the topic of object-oriented design for a chapter with a game. Trying to talk about object-oriented design in a vacuum isn't terribly productive now. Now we'll cover the basic building block of OOP: the class.