Data Encapsulation

If we like the button, we will want to use it for all four answer options. Our instinct is to copy the button for each of four answers (Figure 2.7). This instinct is fine, but immediately we encounter an important problem. Each button is an instance of the same object, and that object is programmed to display the contents of the string variable text. That means that when this movie runs, all four buttons will always sport identical labels (Figure 2.8). The buttons may delight the eye and tickle the mouse finger, but if they offer no actual choice, the players will find this quiz game pretty dull.

Figure 2.7. The Copied Button

Figure 2.8. Four Buttons ”One Variable

Consider various strategies for correcting this problem.

• Return to static text. We probably don't want to do this. Remember that each of our fancy buttons now has six unique text keyframes. Creating a new simple quiz is no longer merely a tedious ordeal of setting 40 graphic text controls. It is now the impossible chore of programming 240 of them.

• Create a unique variable for each button ( text0, text1 textn ). A way to escape from the purgatory of cut and paste might be to establish a special variable for each answer option. Creating a new question now requires only a single assignment of each answer option string:

   text0="Snickers"; text1="Mounds"; text2="Runts"; text3="Payday"; 

  This looks better at first. But implementation of this scheme will introduce nasty compromises into the button design. To link the button to this text, the button code must include the variable name. We are now talking about four different buttons, alike in every way but the name of a variable.

  This is messy. It destroys the sense that the button is an abstracted prototype that is applicable everywhere. And it limits the number of answers that a question can have.

  Perhaps worse is the practical fact that this scheme will freeze development of the button. It seems pretty and bouncy now, but in the future (maybe 10 minutes from now) we might want to tweak it. We would have to replicate each tweak for all four buttons. In real life, we would leave it untweaked.

• Apply object-oriented data encapsulation. We can eliminate the problems of proliferating edit points by developing a somewhat more complex object structure. This kind of solution will be our choice again and again in this book. The solution is not free: In exchange for eliminating the chore of performing multiple edits (and remembering where they are), we are required to understand more complex structures built of layered abstractions. As designers, we must create these structures with enough architectural clarity that they can be understood by other restless programmers ”such as our future selves.

  This task embodies the noble attributes of every programmer: intelligent appetite for abstraction, distaste for hard-coded hacks and lazy aversion to any repetitive task. Our problem is to differentiate the text data used by one button from the data that another button refers to by the same name.

  Buttons themselves cannot encapsulate data. Specifically, they share the namespace with the MovieClip in which they are instantiated . A MovieClip (the base movie or any other) that contains four button instances has only one text variable.

Note

N AMESPACE

Namespace is an important concept in programming. It is the same as scope. Namespace refers to the phenomenon of the same name having different meanings, depending on where it is used. For instance, the identifier "Dad" could refer to billions of people, but there is only one Dad (normally) in any given family. Namespace is similar. Different objects can have properties with the same names . But because each property is accessed within the context of a different object that it resides in, each is different.

The MovieClip itself has a unique namespace. Thus a MovieClip containing four MovieClip instances can have five unique text variables : its own and one for each of the submovies. It does not matter if the four instances are of the same MovieClip symbol (prototype) or not.

So by wrapping our button in a MovieClip, we can make it addressable.

ActionScript

 answer0.text="Snickers"; answer1.text="Mounds"; answer2.text="Runts"; answer3.text="Payday"; 

Though this seems similar to the previous solution, it is very different. There is only one AnswerButton button object and, in fact, only one AnswerOption MovieClip object (see Figure 2.9). Labels like answer0 and answer1 refer to instances of the AnswerOption symbol. AnswerOption contains a single instance of the AnswerButton. The base movie has four instances of AnswerButton, but they are encapsulated in the answer0, answer1, answer2, and answer3 AnswerOptions.

Figure 2.9. Buttons and MovieClip Symbols

Flash does not allow us to name button instances because button instances do not have private namespaces. We can address only the internals of named MovieClip instances. In Flash, the term target is used to refer to a such a named instance.

For historic reasons, Flash has two ways to address targets and their member components . In Flash 4, we struggled to learn a notation that imitates Unix and URL conventions. Object levels are separated by slashes . Variables are separated by colons. Parents are indicated by double dots and the root by a leading slash. In contrast, Flash 5 introduced ECMA style notation (Table 2.2). Everything is separated by dots. Roots and parents have special names. Despite its wordiness and ambiguity (see _root. carrot and _root.carrot in the table), the ECMA notation is undoubtedly superior and is used throughout this book. The ambiguity demonstrated in the table is overcome by the restriction that a MovieClip object and a data variable cannot use the same name in the same namespace.

Table 2.2. Different Syntax for Reference

WHAT WE ARE REFERING TO	SLASH “ COLON SYNTAX	DOT SYNTAX
My variable bar	bar	bar
my child foo 's variable bar	foo:bar	foo.bar
root variable carrot	/:carrot	_root.carrot
root MovieClip carrot	/carrot	_root.carrot
carrot 's submovie tip	/carrot/tip	_root.carrot.tip
my grandfather's dentures	../../:dentures	_parent._parent.dentures

Now that we have an AnswerOption that is more capable than the AnswerButton, we need to retrofit our Question display. Returning to the Start frame, we can right-click on each of the buttons, one at a time, to automatically select the correct keyframe and bring up the Instance panel.

The leftmost icon is Swap Symbol. Use it to change each of the AnswerButton references to AnswerOptions.

Click the desired choice, and then set the behavior and name it.

Data-Driven Flash

At last we can act like programmers, not clerks. By addressing each instance of the AnswerOption object by name, we can inject data into it (see Figure 2.10).

Figure 2.10. Four Buttons ”Four Variables

 answer0.text="William the Conqueror"; answer1.text="William the Bastard"; answer2.text="William the Bald"; answer3.text="William the Duke of Normandy"; stop (); 

The text, of course, will be visible only as the movie plays.

It is a little disturbing to write to a variable ( text ) that not only does not yet exist but is in an other object's namespace ( answer0.text ). Certainly it violates the principles of real object-oriented programming to directly write to a variable that resides in another object. Normally a method of the class would be especially designated to set the text (so that the fundamental design of the object could change, but no code that uses the object would have to). It is shocking simply to write to one that does not even exist. (The AnswerButton will read the text variable but does not declare, define, or assign it.) The primary reason is to prevent accidental overwrites and other miscommunication between programmers, or between us and us when we come back to the code in three weeks.

But this is valid ActionScript. It is a feature of scripting languages like ActionScript and JavaScript (and, as we will see later, PHP) that variables can be established simply by assignment ”they need not be declared.

It is also true that ActionScript variables are visible globally. Some other object-oriented languages allow us to restrict access to our object's variables. Data hiding ”the protection of an object's variables by the privacy of its namespace ”offers a higher degree of security, something like the protection of an unlisted phone number. Although the access syntax and the usage of MovieClip variables are similar to those of the instance variables of an object, this is not pure object-oriented programming. This form of data encapsulation provides for instantiation and packaging of variables for each MovieClip but not data hiding.