ActionScript Overview: Chapter 1 - Learning ActionScript 3.0
Pages: 1, 2

Section 1.3: Procedural Versus Object-Oriented Programming

Much discussion has been made over the pros and cons of procedural versus object-oriented programming. To touch briefly on this, here is a little background concerning the evolution of ActionScript. ActionScript started as a sequential programming language, meaning that scripting was limited to a linear sequence of instructions telling Flash what to do in a step-by-step manner. This approach to scripting was not terribly flexible and did not promote reuse.

As the language evolved, it became a procedural programming language. Like sequential programming, procedural programming relied on a step-by-step set of instructions but introduced a more structured, modular approach to scripting. Procedures, otherwise known as functions (or, sometimes, subroutines), could be executed again and again as needed from different parts of a project, without copying and pasting copies of the code into the ongoing sequence of instructions. This modularity promoted reuse, and made the code easier to edit and more efficient.

Scripters in search of an even greater degree of modularity and reuse gravitated toward object-oriented programming. OOP languages create programs that are a collection of objects. Objects are individual instances of classes—collections of code that are self-contained and do not materially alter or disrupt each other. Dividing code into small capsules, appropriately known as encapsulation, is one of the hallmarks of an OOP language. Another important feature of OOP is inheritance, or the ability to derive classes from parent classes, passing on specific characteristics from the parent.

A classic example of OOP structure, and specifically inheritance, defines a set of transportation vehicles. You might start with a generic Vehicle class that includes traits common to all vehicles, such as the basic physics of movement. You might then create three subclasses: GroundVehicle, WaterVehicle, and AirVehicle. These classes would alter or introduce traits specific to ground, water, and air travel, respectively, but not yet be complete enough to represent an actual vehicle. Further derived classes might be Car and Motorcycle (descending from GroundVehicle), Boat, and Submarine (descending from WaterVehicle), and Plane and Helicopter (descending from AirVehicle). Depending on the complexity of your system, you can carry on this process, creating individual models with individual settings for fuel consumption, friction, and so on.

As you can probably imagine, this approach to development adds additional power, flexibility, and prospects for reuse. These benefits, among others, sometimes position object-oriented programming as the best approach to a problem. However, there is a tendency among some programmers to believe that OOP is the best solution to all problems or, effectively, the only solution. This is a faulty assumption.

OOP is often best for very large projects, or for working with a team of programmers, but it can often be overkill for small projects. Additionally, for the uninitiated, it can significantly increase the learning curve, and distract from key topical concepts during your studies. In short, OOP is not always the best tool for the job. Procedural programming still has its place, and Flash CS3 allows you to explore and employ both programming paradigms.

This book attempts to introduce material using both procedural and OOP where appropriate. Using object-oriented practices is a fine goal, and one that we will encourage in this volume. However, we will try first to focus on the material central to each chapter, highlighting syntax and explaining how and why each topic should be addressed in code.

In general terms, we will focus on procedural programming prior to Chapter 6; this chapter serves as a transition chapter between procedural and OOP practices. After Chapter 6, the beginning of each chapter will focus on the topics being discussed, without intrusion by the surrounding OOP class structures. When appropriate, however, each chapter will end with an applied OOP example.

This is our preferred approach to presenting material for all possible users—in both procedural and OOP formats. It is our hope that, regardless of your skill and experience, you will home in on the topics at hand, and then work in the timeline, or in classes, based on your comfort level.

Section 1.4: The Document Class

If you decide you would like to start thinking in OOP terms right away, we will show you how to easily take a step in that direction. Flash CS3 introduced a new feature that simplifies associating a main class, or application entry point with your FLA. It is called the document class and it does all the work of instantiating the class for you. This means you don't need any code in the timeline at all, and can edit all examples in Flash or the external text editor or development environment of your choice.

If you don't plan to start using OOP until we roll it out in later chapters, feel free to skip this section as it will be repeated in . We will provide minimal explanation here just to get you going using the document class, and will explain this material in greater detail in later chapters throughout the book.

Let's start with a simulated chapter example that you might use in the timeline. It does nothing more than use the trace() method to place a word into the fOutput panel—an authoring-only panel that accepts text output from your file.

trace("Flash");

To create a document class, you're going to create a kind of wrapper that encloses the trace() method in the correct class syntax.

Create a new ActionScript file (rather than a new FLA document) and type the following document class shell:

1   package {
2
3      import flash.display.MovieClip;
4
5      public class Main extends MovieClip {
6
7          public function Main() {
8
9          }
10
11      }
12  }

The first line, along with the closing brace in line 12, defines the class's package. A package is a mandatory structure that ensures your class is known to the compiler. Next, you must import any classes that you need to use in your package.

A document class essentially serves as a shortcut for creating an instance of a movie clip or sprite (a new Flash object that is nothing more than a one-frame movie clip) and adding it to the display list so it can be displayed by Flash Player. (This is true even when there is nothing to display, as in this case. We will cover manipulating the display list in Chapter 4.)

All document classes must be derived from either the MovieClip or Sprite class. (Other custom classes that are not document classes do not need to be extended from MovieClip or Sprite if that is not appropriate.) This example uses MovieClip so you must import the MovieClip class, as seen in line 3.

Line 5, along with its closing brace on line 11, is the class definition. Its name is arbitrary but, when naming it, you should follow a few basic rules and conventions. The name should be one word that does not already exist in ActionScript, it should start with an alpha character (rather than a number or other character), and it is typically capitalized. The class must be public, meaning that other classes can access the constructor, and it must extend MovieClip or Sprite, as described previously.

Line 7, along with its closing brace on line 9, is the class constructor. This is the main function that automatically runs when creating an instance of this class. It, too, must be public and must have the same name as the class. Other functions (if any) can, and must, have unique names. All that remains is to add the lone method required in this case. The constructor must trace "Flash" to the Output panel, so add the following to line 8:

7        public function Main() {
8            trace("Flash");
9        }

Once finished, you must save the file in the same directory as your FLA file for now. (Later on, you'll learn how to place your class files in other locations.) You must give the file the same name as the class, but add an .as extension. Therefore, this file should be named Main.as. Now create a new FLA file, choosing ActionScript 3.0 as its programming language version, and save it in the same directory as your previously created class file. The name of the FLA is unimportant.

Finally, open the Properties Inspector and add the name of your document class, not the name of the document itself, in the Document Class field. In this case, type Main instead of Main.as, as seen in this figure.

Example
Figure : Adding a document class to your FLA

Now preview your file. Doing so will create an instance of the Main class (which extends MovieClip and, therefore, behaves like a movie clip) and add it to the display list. The class will trace "Flash" to the output panel, and your test application will be complete.

Hereafter, you can try any of our timeline code in a document class of your own. Initially, you probably won't know which classes to import or how to make any possible changes to variables or similar structures to conform to the class syntax. However, all the sample code will come with an accompanying class file for testing. You can use those files whenever you wish until you get used to the document class format.

Section 1.5: Legacy Code Compatibility

I'd like to end this chapter with a small caveat. You cannot mix ActionScript 1.0 or 2.0 code with ActionScript 3.0 code in the same SWF. You are unlikely to do this if you're learning from scratch, but you may run into this situation if you attempt to update legacy projects by adding ActionScript 3.0 code.

If you ever have the need to run a discrete mixture of ActionScript 3.0 and a prior version of the language, such as showing a legacy file within a new demo interface shell, you can do so by loading a SWF. An ActionScript 3.0 file can load a SWF created in ActionScript 1.0 or 2.0, but it cannot access the older SWF's variables or functions. For all intents and purposes, the same is not true in reverse. An older SWF cannot load an ActionScript 3.0 SWF.

In Chapter 13, we will discuss how to communicate between these two discrete SWFs using a special process. For now, however, just remind yourself again that you cannot combine ActionScript 3.0 with older versions of the language in the same file.

Section 1.6: What's Next?

Now that you know a little more about ActionScript 3.0 and the Flash Platform, it's time for a look at some of the fundamentals of the language. By reviewing version-independent concepts at the outset, we can focus on new syntax in subsequent chapters. If you have a lot of experience with ActionScript 1.0 or 2.0, you may wish to skim this material.

In the next chapter, we'll discuss:

  • Basic concepts to bring you up to speed quickly, including using the trace() method as a diagnostic tool to see immediate feedback from your scripts
  • Using variables to store data, including arrays and custom objects that allow you to easily manage more than one value, and data typing those values to improve error reporting
  • Logical structures such as conditionals for decision making and loops for simplifying repetitive tasks
  • Functions that can isolate code into convenient blocks that will be executed only when instructed
  • Ways to address Flash objects with ActionScript, including using absolute and relative paths, and the shortcut identifier this

This excerpt is from Learning ActionScript 3.0. Learning ActionScript 3.0 gives you a solid foundation in the Flash language and demonstrates how you can use it for practical, everyday projects. The book does more than give you a handful of sample scripts, defining how ActionScript and Flash work. It gives you a clear look into essential topics such as logic, event handling, displaying content, migrating legacy projects to ActionScript 3.0, classes, and much more. Written for those new to the language, this book doesn't rely exclusively on prior knowledge of object-oriented programming (OOP). Instead, it helps you expand your skillset by first focusing on clear, concise examples in the timeline, evolving into OOP examples over time-allowing you to choose the programming approach with which you are most comfortable.

buy button