2.3 But How Do I Apply OOP?
| < Day Day Up > |
| Many people learn the basics of OOP only to say, "I understand the terminology and concepts, but I have no idea how or when to use them." If you have that feeling, don't worry, it's perfectly normal; in fact, it means you're ready to move on to the next phase of your learning ” object-oriented design (OOD). The core concepts of OOP (classes, objects, methods , properties, etc.) are only tools. The real challenge is designing what you want to build with those tools. Once you understand a hammer , nails , and wood, you still have to draw a blueprint before you can actually build a fence, a room, or a chair . Object-oriented design is the "draw a blueprint" phase of object-oriented programming, during which you organize your entire application as a series of classes. Breaking up a program into classes is a fundamental design problem that you'll face daily in your OOP work. We'll return to this important aspect of OOP regularly throughout this book. But not all Flash applications need to be purely object-oriented. Flash supports both procedural and object-oriented programming and allows you to combine both approaches in a single Flash movie. In some cases, it's sensible to apply OOP only to a single part of your project. Perhaps you're building a web site with a section that displays photographs. You don't have to make the whole site object-oriented; you can just use OOP to create the photograph-display module. (In fact, we'll do just that in Chapter 5 and Chapter 7!) So if Flash supports both procedural and object-oriented programming, how much of each is right for your project? To best answer that question, we first need to understand the basic structure of every Flash movie. The fundamental organizing structure of a Flash document (a .fla file) is the timeline , which contains one or more frames . Each frame defines the content that is displayed on the graphical canvas called the Stage . In the Flash Player, frames are displayed one at a time in a linear sequence, producing an animated effect ”exactly like the frames in a filmstrip. At one end of the development spectrum, Flash's timeline is often used for interactive animation and motion graphics. In this development style, code is mixed directly with timeline frames and graphical content. For example, a movie might display a 25-frame animation, then stop, calculate some random feature used to display another animation, and then stop again and ask the user to fill in a form while yet another animation plays in the background. That is, for simple applications, different frames in the timeline can be used to represent different program states (each state is simply one of the possible places, either physical or conceptual, that a user can be in the program). For example, one frame might represent the welcome screen, another frame might represent the data entry screen, a third frame might represent an error screen or exit screen, and so on. Of course, if the application includes animation, each program state might be represented by a range of frames instead of a single frame. For example, the welcome screen might include a looping animation. When developing content that is heavily dependent on motion graphics, using the timeline makes sense because it allows for precise, visual control over graphic elements. In this style of development, code is commonly attached to the frames of the timeline using the Actions panel (F9). The code on a frame is executed immediately before the frame's content is displayed. Code can also be attached directly to the graphical components on stage. For example, a button can contain code that governs what happens when it is clicked. Timeline-based development usually goes hand-in-hand with procedural programming because you want to take certain actions at the time a particular frame is reached. In Flash, "procedural programming" means executing code, defining functions, and setting variables on frames in a document's timeline or on graphical components on stage. However, not all Flash content necessarily involves timeline-based motion. If you are creating a video game, it becomes impossible to position the monsters and the player's character using the timeline. Likewise, you don't know exactly when the user is going to shoot the monster or take some other action. Therefore, you must use ActionScript instead of the timeline to position the characters in response to user actions (or in response to an algorithm that controls the monsters in some semi- intelligent way). Instead of a timeline-based project containing predetermined animated sequences, we have a nonlinear project in which characters and their behavior are represented entirely in code. This type of development lends itself naturally to objects that represent, say, the player's character or the monsters. At this end of the development spectrum lies traditional object-oriented programming, in which an application exists as a group of classes. In a pure object-oriented Flash application, a .fla file might contain only a single frame, which simply loads the application's main class and starts the application by invoking a method on that main class. Of course, OOP is good for more than just video games . For example, a Flash-based rental car reservation system might have no timeline code whatsoever and create all user interface elements from within classes. Most real-world Flash applications lie somewhere between the extreme poles of timeline-only development and pure OOP development. For example, consider a Flash-based web site in which two buttons slide into the center of the screen and offer the user a choice of languages: "English" or "French." The user clicks the preferred language button, and both buttons slide off screen. An animated sequence then displays company information and a video showing a product demo. The video is controlled by a MediaPlayback component. Our hypothetical web site includes both procedural programming and OOP, as follows :
In the preceding example, code placed directly on frames (e.g., the preloader code) is procedural. But the buttons and MediaPlayback component are objects derived from classes stored in external .as files. Controlling them requires object-oriented programming. And, interestingly enough, Flash components are, themselves , movie clips. Movie clips, so intrinsic to Flash, can be thought of as self-contained objects with their own timelines and frames. Components (indeed, any movie clip) can contain procedural code internally on their own frames even though they are objects. Such is the nature of Flash development ”assets containing procedural code can be mixed on multiple levels with object-oriented code.
Flash's ability to combine procedural and object-oriented code in a graphical, time-based development environment makes it uniquely flexible. That flexibility is both powerful and dangerous. On one hand, animations and interface transitions that are trivial in Flash might require hours of custom coding in languages such as C++ or Java. But on the other hand, code that is attached to frames on timelines or components on the Stage is time-consuming to find and modify. So overuse of timeline code in Flash can quickly (and quietly !) turn a project into an unmaintainable mess. Object-oriented techniques stress separation of code from assets such as graphics and sound, allowing an object-oriented application to be changed, reused, and expanded on more easily than a comparable timeline-based program. If you find yourself in the middle of a timeline-based project faced with a change and dreading the work involved, chances are the project should have been developed with object-oriented principles from the outset. Although OOP may appear to require additional up-front development time, for most nontrivial projects, you'll recoup that time investment many times over later in the project. Ultimately, the amount of OOP you end up using in your work is a personal decision that will vary according to your experience and project requirements. You can use the following list to help decide when to use OOP and when to use procedural timeline code. Bear in mind, however, that these are just guidelines ”there's always more than one way to create an application. Ultimately, if the software works and can be maintained , you're doing something right. Consider using OOP when creating:
Consider using procedural programming when creating:
You'll notice that the bulleted item "Highly customized user interfaces that include complex visual transitions" is included as a case in which you might use both OOP and procedural programming. Both disciplines can effectively create that kind of content. However, remember that OOP in Flash is typically more maintainable than timeline code and is easier to integrate into version control systems and other external production tools. If you suspect that your highly customized UI will be used for more than a single project, you should strongly consider developing it as a reusable class library or set of components with OOP. Note that in addition to Flash's traditional timeline metaphor, Flash MX Professional 2004 introduced a Screens feature (which includes both Slides and Forms ). Screens provide a facade over the traditional timeline metaphor. Slides and Forms are akin to the card-based metaphors of programs like HyperCard. Slides are intended for PowerPoint-style slide presentations, while Forms are intended for VB developers used to working on multipage forms. Like timeline-based applications, Screens-based applications include both object-oriented code (i.e., code in classes) and procedural-style code (i.e., code placed visually on components and on the Screens of the application). As mentioned in the Preface, this book does not cover Screens in detail, but the foundational OOP skills you'll learn in this text will more than equip you for your own exploration of Screens. |
| < Day Day Up > |
EAN: 2147483647
Pages: 177