I don’t like attaching classes from the library. Maybe it’s because it makes it easier to lose track of all the classes in a flash project or maybe it’s because with the advancement with AS3, it seems almost silly that you can’t extend a displayObject that already lives in the DisplayList. I’ve been using a method I informally call “class skinning” and I wanted to get some constructive feedback. I create a class that is intended to add functionality to a displayObject but it doesn’t extend anything (well maybe the EventDispatcher for the ability to dispatch events). I pass in the displayObject as a parameter when instantiating the class which becomes the object to reference (instead of “this”) inside the class. Here’s a simple example:
package
{
import flash.display.MovieClip;
import flash.events.MouseEvent;
public class AlphaButton
{
private var _mc:MovieClip //this holds the referenced movieclip
private var _up:Number
private var _over:Number
public function AlphaButton(mc:MovieClip, up:Number, over:Number)
{
_mc = mc;
_up = up;
_over = over;
_mc.buttonMode = true;
_mc.mouseChildren = false;
_mc.alpha = _up;
_mc.addEventListener(MouseEvent.MOUSE_OVER, buttonOver, false, 0, true);
}
private function buttonOver(e:MouseEvent):void
{
_mc.addEventListener(MouseEvent.MOUSE_OUT, buttonOut, false, 0, true);
_mc.alpha = _over;
}
private function buttonOut(e:MouseEvent):void
{
_mc.removeEventListener(MouseEvent.MOUSE_OUT, buttonOut);
_mc.alpha = _up;
}
public function dispose():void
{
_mc.removeEventListener(MouseEvent.MOUSE_OVER, buttonOver);
_mc.removeEventListener(MouseEvent.MOUSE_OUT, buttonOut);
}
}
}
Adding and removing the class skin to a movieclip called “box_mc”:
//adding
var button:AlphaButton = new AlphaButton(box_mc, .5, 1);
//removing
button.dispose();
button = null;
Why would I want to set up a object based class this way? Well, for one, it creates a great deal of flexibility. In the linkage properties of the library, I’m allowed up to 2 classes to attach to a displayObject. By using a class skin, I can attach as many classes as I want to a single displayObject as well as remove it at anytime without having to remove the displayObject itself. I could create a DragButton class that will give “box_mc” drag and drop functionality while the AlphaButton Class gives it MouseOver and MouseOut functionality. Or I could remove one and then add the other dynamically changing the functionality of the displayObject. This also allows me to write my classes very compartmentalized which makes them easy to reuse.
I like to think of each class variable, not as something that takes over and becomes the displayObject instance, but a kind of functionality receipt for each displayObject; a proof of functionality that is displayed in the document class. Looking at it in this way, I could set up a great deal of my different displayObjects’ functionality in a document class, organized and listed one after the other as variables. This turns the document class into a kind of “table of contents” that presents what all my classes are named (AlphaButton) and what displayObjects they apply to (box_mc). It can potentially create a very organized overview for your code. If you happen to pass the project on to another developer, they can instantly see how all the project classes are connected just by looking at the document class.
This method doesn’t have to be limited to just displayObjects either. Take a dynamically loading swf, for example. The swf can be typecasted as a MovieClip, and as such you could create a document class for this swf as a class skin:
var loadedSwf:DocClassName = new DocClassName( MovieClip(swfInstance) );
Why would I want to do that instead of connecting it through the swf’s fla? Because since the class is now instantiated on the root document class, it can now potentially access all the other classes on the stage quickly and easily using just dot syntax rather than listening for dispatched events! I know this isn’t best practice for keeping the class object oriented, but in the case of document classes, they hardly ever get reused anyway.
Of course, just like anything, it has it’s pros and cons. In a gaming project, for example, that needs to add and remove objects from the displayList often, I imagine this method would probably get annoying having to add the class skin everytime an displayObject enters the stage. Also, because the class doesn’t actually extend the displayObject, the class does not inherit the displayObjects properties. So when referring to the “mouseEnabled” property, for instance, of the AlphaButton’s displayObject, you would have to call the displayObjects instance name (box_mc.mouseEnabled) instead of the class skin variable (button.mouseEnabled). However, if a particular displayObject property would be beneficial to access through the class itself, you could simply add a getter setter to the class like so:
public function get mouseEnabled():Boolean
{
return _mc.mouseEnabled;
}
public function set mouseEnabled(bool:Boolean):void
{
_mc.mouseEnabled = bool;
}
Please let me know your thoughts, thanks.
