Interfaces are amazing things. When I was young and green, I didn’t understand their purpose, but after working with them for a while, I will defend their use to the end. I try to create lots of interfaces early on in my projects and I find that by keeping things flexible, it saves more time despite the extra typing, pardon the double entendre.

But this is not an article about why interfaces are so great. No, this is an article about the mysterious gap in the Flash Player API with regards to an interface for DisplayObjects. If you have a class typed as something like IView, there’s no way to enure that IView can be a parameter of display list functions like addChild().

Why can’t we guarantee that something is a DisplayObject through interfaces? There is a practical answer. The inner workings of the Flash Player are slowing unfolding to us with each version. We now have low level access to sound, byte streams, and text rendering. However, the display list still relies exclusively on one of the only truly abstract classes in ActionScript 3.0, the DisplayObject. Because a low-level drawing engine is not exposed to AS3 programmers, we don’t know how it works and we cannot guarantee through an interface that an arbitrary class can be drawn.

Fortunately, there are some workarounds that can help, each with their own strengths and weaknesses. Personally, I think #2 is the way to go. It’s practically dripping with polymorphic goodness.

1. Make your interface inherit from IBitmapDrawable and IEventDispatcher

   DisplayObject is the only class that uses both of these two interfaces so by combining them in your interface, you can sort of be sure you’re working with a DisplayObject. Still, this is my least favorite solution

   Pros:

   • Uses interfaces exclusively.
   • Only a DisplayObject would implement both of these.

   Cons:

   • There’s nothing to stop you from using this to create a class that isn’t a DisplayObject and that could cause problems.
   • You would still have to type cast to DisplayObject to use this as an argument for addChild().

2. Create an interface that exposes a method to return the object as a DisplayObject

   My personal favorite solution. It not only solves the problem of guaranteeing that a class can go in the display list, it doesn’t even require that the class be a DisplayObject.

   Here’s an example of what this would look like. IDisplayObject.as

   Pros:

   • Flexible solution that conforms to good OOD principles.
   • Uses interfaces exclusively.
   • Easy to apply. You can usually implement it with a single line of code: return this;

   Cons:

   • Requires you to use asDisplayObject() every time you want to use the object as a DisplayObject.
   • Calling foo.asDisplayObject() would throw an exception if foo was null so additional checks may be necessary.

3. Use an abstract class that inherits from DisplayObject

   Not an ideal solution primarily because Flash doesn’t have true abstract classes (although there are workarounds) but still totally valid.

   Pros:

   • Guarantees that the object is a DisplayObject. No type casting required.
   • Abstract classes can be treated virtually the same as an interface for practical use.

   Cons:

   • No true abstract classes in Flash.
   • Not as flexible as an interface-based solution since it forces you to inherit from DisplayObject.

Step 1: download the Flex 4 SDK and the Flash player 10 (debug version).

Step 2: Create a fresh config file that will target Flash player 10.

Step 3: Use MXMLC to compile your Actionscript or MXML file.

Step 4: Explore AS3 with Flash 10!

I’ve only tinkered around a bit at this point. But as soon as I get a chance to build a crazy app, I’ll have a more thorough write-up. So far, I’m quite excited at the new features. Be sure to read up on the following:

new Vector class

The inverse kinematics package

The new Shader class

The all new text engine package