Chapter 13. MovieClip Subclasses

From an application development perspective, a movie clip is a self-contained multimedia object with a timeline for changing state (you can think of animation in a movie clip as a rapid succession of visual state changes). Movie clips can contain graphics, video, and audio. They are, hence, perfect for creating the audio/visual elements of an application ”so much so, that every one of Flash's own components are, in fact, descendents of the MovieClip class.

We've already seen lots of examples of how movie clips can be used in OOP. Most of these have involved object composition, in which a movie clip instance is stored in an instance property and used by a class to represent something visual on screen. In the composition model, the class that uses the movie clip does not inherit from the MovieClip class. For example, in the Box class from Example 4-6, we create a movie clip in which we draw a square shape. We store that movie clip in an instance property of the Box class, but the Box class does not inherit from the MovieClip class (i.e., it does not extend MovieClip ).

As an alternative to object composition, we can use inheritance to marry one of our own classes to the MovieClip class. When taking the inheritance approach, we should feel confident that the custom class in question really "Is-A" kind of MovieClip . In other words, only when an application calls for a class whose instances can be used exactly like MovieClip instances but also require their own special features should we consider making that class a subclass of MovieClip .

Let's put our Box class to this test. In our first implementation, the Box class used a movie clip to render Box instances on screen, but it did not inherit from MovieClip . Should it have? To answer that question, we must ask whether a Box instance is a specialized variety of MovieClip . If Box instances need all of the features of MovieClip instances, then the Box class could sensibly be a MovieClip subclass. If not, a Box isn't really a specialized variety of MovieClip , so it probably shouldn't be a MovieClip subclass.

Do Box instances need all the features of MovieClip instances? Do they need to be dragged with the mouse? No. Do they need to be able to create text fields? No. Should we be able to check the number of bytes loaded by a Box instance? Or set the mask over a box? No and no. None of these features are immediate requirements of the Box class. Furthermore, a Box instance doesn't need a timeline or the timeline control methods of the MovieClip class. It doesn't seem as if a Box "Is-A" MovieClip . In fact, a Box more likely "Is-A" Shape ! If, in a larger application, we made the Box class a MovieClip subclass, then it wouldn't be able to inherit from a more natural superclass, such as Shape . Our original composition-based design was probably the better choice.

The warning here is a refrain from Chapter 6 ”don't inherit from a class just to borrow some of its functionality; make sure the "Is-A" relationship exists before extending a class. If you're creating a new kind of generic multimedia class that uses most or all of the features of MovieClip , by all means subclass MovieClip . (The Flash UI Components fall into that category.) But if you're just trying to draw something to the screen, make sure you prudently consider composition before opting for an inheritance implementation.

Now that we've considered when to subclass MovieClip , let's see how to subclass MovieClip .