A Closer Look
Gentle Reader Every now and then I run into something of possible interest to ActionScript 3.0 and Design Patterns. Since I spend a lot of time in the forest (Design Patterns), I may miss the trees (Program Elements). So what I may run across might be known (and obvious) to all but me. On the other hand, some may find these short digressions of possible interest and use. So as to alert readers to these random snippets I put together a Closer Look logo for these small posts that live in the nooks and crannies of OOP and Design Patterns.
Programming with MovieClips in the Library
When you create a MovieClip in the Library and set it up for Export to ActionScript, you can treat it as a child of the MovieClip class. Basically, a named MovieClip in the Library is the same as setting it up as:
public class MyMC extends MovieClip …
One of the fundamental design pattern principles is program to an interface; not an implementation. For example, instead of declaring a movie clip instance as,
private var myInstance: MyMC = new MyMC()
we’d write it, thusly to program to the interface:
private var myInstance: MovieClip = new MyMC()
We could even make it looser by typing it as a Sprite instance;
private var myInstance: Sprite = new MyMC()
Does it really matter? I believe that programming to the interface instead of the implementation definitely matters, but whether it is to the Sprite or MovieClip depends on what you need.
Create two movie clips that you can place in the Library. One is a simple green block. The second movie clip does a shape tween turning from blue to green as it moves from left to right. Now, consider the following program:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 | package { import flash.display.Sprite; import flash.display.MovieClip; public class Client extends Sprite { private var sansTL:Sprite; private var conTL:MovieClip; { public function Client() { //No Timeline use sansTL=new NoTL(); sansTL.x=100, sansTL.y=100; addChild(sansTL); sansTL.rotation=20; //rotation property assigned value //Needs Timeline method conTL =new McTL(); conTL.x=100, conTL.y=200; addChild(conTL); conTL.gotoAndStop(6); //gotoAndStop() method used //(cannot be used by Sprite) } } } } |
If you type a movie clip instance as a Sprite, you can use all of the Sprite properties and methods, but you cannot use the additional MovieClip properties and methods that use the timeline. Figure 1 illustrates what the above program does.
Figure 1:Two differently typed movie clip instances
Like I said, this was one of those little things that hit me and amounts to no great shakes. However, if I plan to use drawn figures in the Library as imagery and nothing more, I would type them as Sprites—why bring along the Timeline if I’m not going to use it? (In Part II of the Wrong Way Warrior, all of the images were static MovieClip instances typed as Sprites.)
The A Closer Look: Programming Library MovieClips to an Interface by William B. Sanders, unless otherwise expressly stated, is licensed under a Creative Commons Attribution-Share Alike 3.0 United States License.
Bill Sanders
Are there ant statistics on how much memory we earn in this way?
Hi Tolis,
I was thinking the same thing, and I didn’t find it made a lot of difference. (I did not create a very sophisticated test example, though.) Some Design Patterns, such as the Flyweight, can be shown to use less memory and execute faster, but on the whole I really don’t think that you’re going to find design patterns helping out in speed and memory usage. They were not designed to do that.
Sprite has the following subclasses:
•DownloadProgressBar
•FlexSprite
•HTMLLoader
•MovieClip
•Preloader
If I type my object to a MovieClip but I’m not using any of the timeline methods, I would not be able to use as wide a variety of subclasses in my structure. For example,
var keyStructure:MovieClip =new HTMLLoader();
would not work. However,
var keyStructure:Sprite =new HTMLLoader();
works fine. The main reason for using a higher level type is to gain the ability to have a wider set of options in your design structure. In other words,
And that’s what you want.
Kindest regards,
Bill
Bill,
I’d like to dig deeper into this issue as I use this technique frequently. How is ‘private var myInstance: MyMC = new MyMC()’ different than ‘private var myInstance: MovieClip = new MyMC()’? When you create a new Symbol in the library most likely you’ll choose MovieClip. So what is to be gained by the second line of code, don’t you have all the functionality of the MovieClip class already? Even one step further, I usually associate a unique class with the library item in the Linkage menu. That class has to extend MovieClip or it won’t work.
Thanks again, for maintaining this blog. I appreciate the effort you put in.
Alex
Hi Alex,
When dealing with most design patterns, you’ll have interfaces in terms of either abstract classes or ActionScript interfaces. I like to think of everything in terms of either being a concrete class or a parent class–the parent containing the interface. In building a design I want to keep them as loose as possible. Quoting from the Gang of Four:
MovieClips in the library are not instances of the MovieClip class. They are classes in their own right—they extend the MovieClip class. (You already knew that!) Take for example, the Wrong Way Warrior Part I. In it, I subclassed the Warrior to Red and Blue classes. Each contained an instance of the RedWarrior and BlueWarrior taken from the Library. Suppose that the developer wanted to include the image reference in the Warrior class itself and when subclassed, the Red and Blue classes got a WarriorImage property. It is typed as a Sprite (or a MovieClip for that matter). If it were typed as a RedWarrior, it would have been impossible to generate a Blue subclass that could request a BlueWarrior because it was typed as a concrete class and not the interface.
Here’s how to think of programs. They are young men or women who cannot commit. Archie likes both Betty and Veronica; so he doesn’t commit to either. He just commits to Women. Then he meets Stupefyin’ Jones, yet another woman. Can he date Stupefyin’ Jones? You bet! He’s just committed to the Women class, and not any single subclass.
I don’t mean to act silly about this, because it’s really a good question. Rather, I’m trying to find an analogy that will both make sense and is easy to remember.
Kindest regards,
Bill
Hi there.
When I do type my linked symbols just to MovieClip I do not get code-hinting in IDE’s like FlashDevelop. I can only chose from Movieclip methods – the onces from my own class (like shot() in a warrior class) are hidden, because I’m only dealing with a generic Movieclip.
Hi Mark,
That’s one thing I’ve found out about using design patterns in general—you lose a lot of code hinting. However, for me, when it comes to following good OOP practices or having code-hinting; I would rather follow good practices.
It’s not easy developing with design patterns!
Thanks once again for your insights,
Bill
If you are using FlashDevelop you can upcast your object to get code hinting on your object eg:
var instance:MovieClip = new MovieClip();
(instance as Concrete).someMethod();
You are not changing the type but asking flash to consider it for this moment as another type.
Hi FlashDev2007,
I’ll bet a lot of people who read this blog use FlashDevelop, and your tip is certainly a helpful one. If you have any other tips or ideas about design patterns, please feel free to share them.
Thanks,
Bill
@ FlashDev: I understand what you are trying to say but I don’t believe that has anything to do with FlashDevelop and the code you posted would only work if “Conrecte” is the superclass of MovieClip ( is part of the top inheritance chain ). But don’t get me wrong, I understand your point, the idea is right, just that the example you have posted is wrong.
I’m guessing that you are casting “instance” to Concrete so that you’ll get some code hinting inside Flash Develop and to avoid compiler errors in certain situations, but as I said, the example posted by you ( as it is ) it not really correct. Something like this would have been more correct:
var dog:Animal = new Dog();
(dog as Animal).bark();
// where bark(); would be a method implemented only by Dog class ( not shared by the Animal interface ) and also you won’t get any code hinting if you leave the instance to be treated as a generic “Animal” and if I’m not mistaking, the you should also be thrown an 1119 compiler error ( http://livedocs.adobe.com/flash/9.0/ActionScriptLangRefV3/compilerErrors.html ) since the compiler wouldn’t recognize “bark()” on Animal.
Taking the idea one step further and coming back to Bill’s original example, we could also use Object or DisplayObject as the type, the common interface ( var mc:DisplayObject = new YourMC(); ) which would also be correct ( since in the end, almost everything inherits from Object ). What’s the difference? Well, not specifying the correct interface might also have certain drawbacks: like the two issues I already mentioned ( code hinting and compiler errors ). For example, what’s wrong with: var mc:DisplayObject = new YourMC(); ??
Well, just try disabling “mc” by setting mc.enabled = false; Guess what? That’s right, you’ll get an 1119 error! Why? Because although DisplayObject is a totally valid type for YourMC ( which extends MovieClip ), it does not have an “enabled” property. The property “enabled” only comes into play in the MovieClip class ( not even the Sprite class has this property ).
So, how to solve this? Simple, do what FlashDev2007 suggest, use casting:
var mc:DisplayObject = new YourMC();
(mc as MovieClip).enabled = false;
It will not throw any errors and it will also work as expected. To conclude: programming to an interface is really useful and important ( just think about polymorphism or the Strategy pattern – better said, all patterns ) but choosing the correct interface ( type ) is also important if you want to avoid continuous casting and compiler error ( Flash IDE can disable “strict mode” and I think that these errors are ignored if “strict mode” is disabled, but DON’T DO IT!!! The best solution is to learn to write clean and correct code and to choose the correct interface for the correct problem ). :)
Cheers,
Barni
“If you type a movie clip instance as a Sprite, you can use all of the Sprite properties and methods, but you cannot use the additional MovieClip properties and methods that use the timeline. Figure 1 illustrates what the above program does.”
I somehow oversaw that piece. :) Well, this is partially correct. I already explained in the above comment why. If YourMC extends MovieClip then at “it’s core” it’s still a MovieClip, even if you type it to Sprite when instantiating the class. It is true that the compiler will throw erros if you try to call methods on it that are only present in the MovieClip class but that doesn’t mean that you can’t “hack this” by casting your object and calling the desired MovieClip methods. You know that YourMC extends MovieClip, so just because you limit it’s functionality to a Sprite ( setting the instance’s type to Sprite ) it doesn’t mean that it’s not a MovieClip anymore… It’s still a MovieClip “at it’s core” just that you are treating it as a “dumb MovieClip” which is at “a Sprite level” ( it only knows to do the things a Sprite can – but this can be changed if you cast it ).
Please correct me if I’m wrong.
Cheers,
Barni
Hi Barni,
It’s not that you’re wrong, it’s that I try and type to an interface whenever possible. (A recommended good habit from GoF.) By typing it as a MovieClip, I type to the Library class’s interface and not the class I created in the Library. Going further, if I typed it to a Sprite, it will loosen it up even more—maybe too much!
Kindest regards,
Bill
Hi Bill,
I hope you didn’t understand my comment the wrong way. I’m totally cool with interfaces, and I also recommend that people use interfaces whenever possible. I quoted your words because you were saying that if you instantiate YourMC ( which extends MovieClip ) and type it to Sprite then “you cannot use the additional MovieClip properties and methods that use the timeline”, which is incorrect. At it’s core, you are still dealing with a MovieClip, and you can still use the YourMC’s MovieClip methods even if it’s typed to Sprite. You just need to cast YourMC to MovieClip to avoid compiler errors ( because you are explicitly telling the compiler “treat MyMC as Sprite although it’s a MovieClip” and that’s exactly what the compiler is doing… but that still doesn’t mean that you can’t also use the MovieClip specific methods of MyMC ).
I totally understand your point. Casting would tighten the code and the whole “implement to an interface” principle would kinda loose it’s sense if we were to type or object to Sprite but still continue to use it as a MovieClip. I’m totally on your side on this, all that I’m saying is that your affirmation ( the one I quoted ) is a bit incorrect ( better said missleading ). After reading piece of text, people might tend to think that “ohh, I typed YourMC to Sprite so it’s not a MovieClip anymore and that’s why I can’t use MovieClip specific methods on it” which is incorrect because YourMC is still a MovieClip just that you are explicitly “dumbing YourMC down” so it will only remember the Sprite methods… like “amnesia”, the object only remembers certain things about itself although it’s a “full grown MovieClip” at it’s core ).
I hope you understand my points now. Also, there’s a comment waiting for moderation ( maybe you didn’t read that one and that’s what caused the confusion with this last comment ).
With kind regards,
Barni
Hi Barni,
Sorry my example was incorrect but you understood the point I was making. I think that the power of typing say a MovieClip to Sprite or DisplayObject in your example, comes when you want to swap it out for something else.
If the object you wanted to swap out was typed as MovieClip and you wanted to use a Sprite, it would not work. But with your example it would work a treat.
I hope between us we have helped someone else.
Thanks
Neil
Hi Neil,
Implementing to an interface is not only great for swapping objects but as Bill keeps on repeating “it loosens coupling”. Why is this important? Because if you have a loose structure then it’s more likely to “be open to change” than strong-typing objects which limit your final structure.
For instance, let’s take the “Dog example”: imagine you have a beauty saloon for dogs, but you have just started the saloon and your employees don’t have experience with all kind of dogs or styles. So, the first few months you only deal with a “limited type of dogs”. Creating an “Animal” interface that would implement “default dog behavior” will loosen your structure so that once the saloon starts to make some serious profit so you can hire more professional, you will also be able to accept newer breeds of dogs. Having the dogs typed to a generic interface like Animal will make future extensions easy… even if your saloon never dressed a Chivava before, creating a Chivava class that implements the Animal interface will let your treat the Chivava as any other dog without having to make any changes to your existing code.
So, implementing to an interface not only lets you swap objects around but also lets your extend the current structure much easily without having to alter existing code. Also, it’s good to implement to an interface from the beginning because you might never know what the future holds ( always try to “plan ahead” )… having a loose and flexible structure is always Thumbs Up ;)
Cheers,
Barni