Steven Kury: Interactive Media Development, Business Analyltics and Strategy

Introduction to Object Oriented Design With Movieclips

Click here to download the sample Flash 9 file for this tutorial.

Object oriented design (OOD) is more than a buzzword in software and interactive media development, it makes a lot of sense for developing big projects.  When done well, it enables developers to make vast, sweeping changes to a project in the later stages of it.  It also enables developers to create components that are reusable in other projects because the components are self-contained.

However, it is more than a method of project development, it is a way of thinking.  To do it, one has to really just “get” the object oriented (OO) way of thinking.  The problem with OO for interactive media is that there are few resources devoted to interactive media that explain it in a way that it is easily “gotten.”  I remember that when I was in the early years of my interactive media career I had heard a lot about it but none of my multimedia reference books explained it well, particularly Lingo.  They all alluded to how Lingo was object oriented, and referred to the aspects of it that were object oriented, but they did nothing to teach object oriented thinking or design.

I was ready to throw my hands up with it until I came across a book on basic Java programming.  The first two chapters of it made no mention of code or programming, they explained exclusively the OO way of thinking in a way that I easily grasped it. (I actually bought the book just for those two chapters, I had no real interest in Java at the time.) After reading those chapters, it made total sense to me, and I started incorporating it into my professional projects soon thereafter.

The purpose of this tutorial is not to teach OO from scratch.  If OO is of interest to you, and is a fuzzy issue, I recommend that you do the same as I did.  It will become clear rather quickly if you read a well written chapter or two on it.  The purpose of this tutorial is to explain how symbols in Flash, such as movie clips, are object oriented so that you can apply OOD to your projects.

Symbols in the Flash library are analogous to classes in an OO language, such as Java.  They are not the objects themselves, but are the “classes” that objects are instantiated from.  When a movie clip is dragged onto the stage, it is “instantiated.”  The instantiation is the actual object.  If you click on one and look at its properties in the property inspector, it will even tell you which symbol in the library it is an instance of.  On top of that, you can give that instantiation a name.  This is how different instantiations of the same movie clip can be referred to individually.  It is via this name that the properties and methods of each object can be accessed.  They are “encapsulated” in each instance.

Take a look at the example_1.fla file that accompanies this tutorial to see this in a basic, no frills example.  The main timeline has two buttons that call an “accessor” method of an instantiation of the same movie clip symbol.  One button calls the method of the movie clip on the left side of the output box and the other calls the same method of the movie clip on the right side.  As the movie clip instances are derived from the same library symbol, the method calls share the same name and do exactly the same thing.  By the way, these dynamic fields in the movie clips are “properties” of the movie clip objects.  They are “encapsulated” within them, as are the static text fields above them too, and are only modified by the method in the movie clip’s timeline.  To extend the “property” concept one step further, each movie clip instance is a “property” of the main movie.

It is evident that they act individually because each one displays the number that it processes in its own dynamic text field, and returns that number to the main timeline.  If you press each button, you will see the field of its movie clip object update.

First, explore the example_1.fla file to see how it is laid out and test the movie to see it in action. (Also see sample 1 below.) Also, the text field in the input section is editable.  You can change the base number to be passed to the movie clips in the method calls.  Change it before pressing each button in order to see the number returned to the main timeline.



Hopefully, you are now clear on how the movie clip instances operate individually.  Now, return to the example_1.fla file in authoring mode and swap the source library symbol of one of the instances, via the “swap” button it the property inspector, for the other movie clip “class,” right_MC.  Now, test the movie again. (Also see sample 2 below.)




Aside from the different color and title of the right movie clip, there is another noticeable difference.  Whereas the original movie clip merely added 10 to the parameter passed to its processNumber method, the yellow movie clip multiplies the parameter by 10 before returning it to the main timeline.  Press both buttons on the .swf and see how the number returned to the main timeline by each, and displayed in the output text field, is now different.  One is the parameter plus 10 and the other is the parameter multiplied by 10.  Because each movie clip’s functionality is contained in identically named methods, they are interchangeable even though they function differently.

This is because the functionality in question is “encapsulated” in the movie clip object.  The calls to the movie clips from the main timeline don’t see the different functionalities, all that they know is that they send a parameter number to the processNumber methods and receive a number back to display in the output text field.  As far as the method calls are concerned, each method is identical to the other because each is called by the same name, accepts the same parameter, and returns a similar number.  They couldn’t care less about the inner workings of the methods.

Now, imagine that you are developing a sophisticated rich Internet application (RIA) with a liquid GUI.  Imagine also that the GUI has a prototype floating control bar that floats over it that enables you, the GUI developer, to develop the main GUI because it serves as a stop gap for functionality.  While you are doing so, another developer is adding another 100 lines of Actionscript to another version of the navigation bar to make its functionality robust and complete.

To implement this complete control bar in the liquid GUI, you simply have to copy it into the library of the GUI .fla file and swap the prototype bar for it via the “swap” button in the property inspector.  As long as the methods in each have identical names, accept identical types of parameters, and return identical types of return values, they will work identically as far as the main GUI is concerned.

I imagine that you can see the similarity between my simple functioning example and this hypothetical one.  In both you can exchange movie clip symbols that have different, sometimes drastically, inner workings as long as those inner workings are called by the same method names.  This is what I was referring to in the opening paragraph when I said, “it enables developers to make vast, sweeping changes to a project in the later stages of it.”  This is the power of object oriented design.

. . .

Steven Kury, MBA, is an interactive media developer and producer.  Over the past 12 years he has contributed to several rich Internet application (RIA) systems, as well as a breadth of marketing communications solutions.  Contact him at steve@steve-kury.biz or (717) 350-6781 to discuss what he can contribute to your project.