| By Darron J. Schall | Article Rating: |
|
| December 20, 2006 01:00 PM EST | Reads: |
16,340 |
Did you know ActionScript 3.0 supports multiple inheritance? Here's how...
Multiple inheritance is actually possible with AS3, despite popular belief that it's not supported. It's not really multiple inheritance in the true sense of the word going by the strict definition... but there's a way to get the job done in AS3 that behaves almost like the real thing.
What I'm about to show you is not something I would advocate as best practice. Nor is it something that should be (ab)used simply because it's available. I'm not going to get into the debate about Composition versus Inheritance and how Multiple Inheritance fits into the picture. If you're here, it's probably because you want to know how to use this technique. I assume you also know then the various repercussions (and if not, at least have the ability to Google them). As they say, "with great power comes great responsibility."
Various disclaimers aside, here we go...
When you simulate the use multiple inheritance, there are three things you need to do:
- You need to create an interface that defines the methods you want to use.
- You need to create a default implementation for that interface.
- You need to merge the default implementation for the interface into the class you want the methods available in, and mark the class as implementing the interface.
Did you forget that ActionScript 3.0 is a dynamic language and supports a long-since-forgotten-about-since-ActionScript-1-days but still-supported-because-its-in-the-spec #include pragma?
This is where it gets ugly, but stay with me. We'll create an interface, and then write the implementation for that interface in a free-standing .as file that contains just loose ActionScript code. Then, like magic, we'll include that file in our class and have the compiler automatically insert the code. The result? A class that implements an interface, with a default implementation that's separate from the class, and re-usable through many classes.
Here's a concrete example to further drive home the idea:
// In CartoonCharacter.as
interface CartoonCharacter
{
function setSpeechBubbleText( text:String ):void;
}
// In ChartoonCharacter_impl.as
public function setSpeechBubbleText( text:String )
{
trace( "setting speech bubble text to: " + text );
}
// In CartoonDog.as
public class CartoonDog extends Sprite implements CartoonCharacter
{
// Check out that bling bling.. fo shizzle!
#include "CartoonCharacter_impl.as";
public function CartoonDog()
{
// Constructor
}
}
// In CartoonCat.as
public class CartoonCat extends Sprite implements CartoonCharacter
{
// Here it is again... oh no he didn't!
#include "CartoonCharacter_impl.as";
public function CartoonCat()
{
// Constructor
}
}
From the above series of code blocks, hopefully you can see what happened. In our "impl" file we just have a method name and a method body. The method body is the default implementation for the CartoonCharacter interface. In our CartoonDog and CartoonCat classes, we include that default implementation and implement the interface.
If you ask the dog if he's a CartoonCharacter, he'll surely respond that he is. Likewise with the cat...
if ( dog is CartoonCharacter )
{
trace( "bow to-tha wow, yo!" );
}
... but by having the implementation in a separate ActionScript file, it allows us to pretend that both dog and cat inherit from CartoonCharacter. When we change the "impl" file, we change the behavior for all of the classes that #include the file. This is important because in this use case, we have to extend a display object class so we can be added on screen.
Now, I know the first question will be "Why not just make CartoonCharacter a class that extends Sprite and have Dog and Cat extend that?" to which I say, "you completely missed the point of this article."
All that aside, there are a few gotchas to using this technique. In no particular order:
- You can't override the default implementation. Since we're #include-ing, using the override keyword and trying to roll your own won't cut it.
- If you include many "impl" files and they have naming collisions (methods with the same names), you'll get a compiler error and the class won't compile. This is a good thing in my book.
- If your default implementation uses other classes, you have to be careful of the "import" statements since the class that's #include-ing the file needs to import those classes.
- No real help fom FlexBuilder, but that's to be expected.
- .. add your own "you suck, this technique is stupid and doesn't work because of XXX" reason here.
Anyway, like I said, use with caution. There are definitely cases where this approach works well, and there are other cases where it's better to change your architecture and avoid it. I leave it as a thought exercise to you to know when to use it and when not to. Don't go crazy, kids, you might want to keep the training wheels on for this one...
Published December 20, 2006 Reads 16,340
Copyright © 2006 SYS-CON Media, Inc. — All Rights Reserved.
Syndicated stories and blog feeds, all rights reserved by the author.
More Stories By Darron J. Schall
Darron J. Schall, an Editorial Board member of Web Developer's & Designer's Journal, has been programming long before he could drive. In school he studied programming languages, ranging from Basic to Pascal to C++ and eventually moving into Java and C# throughout college. Somewhere in the middle he got hooked on Flash 5 and it's been a crazy love affair ever since. Darron is an independent consultant specializing in RIA development. He maintains a Flash Platform related weblog (www.darronschall.com) and is an active voice in the Flash and Flex communities.
- Ulitzer.com Named Exclusive "New Media" Sponsor of Cloud Computing Conference & Expo
- Adobe’s Aiming ColdFusion at Multiple Clouds
- Cloud Executives Feature on Cloud Computing Expo Power Panel
- Cloud Computing Journal: Adobe to Deliver ColdFusion in the Cloud
- Adobe Reader Sued
- Adobe Unveils LiveCycle Enterprise Suite 2 for Deployment in the Cloud
- Adobe May Cooperate with Apple to Transplant Flash Player to iPhone
- Ph.D. in Twitter Anyone?
- Adobe Flex Developer Earns $100K in New York City
- Eolas Sues the Internet
- Adobe LiveCycle Enterprise Suite 2 for Cloud Computing
- Special Report on the Emerging Cloud Computing Trend
- My Thoughts on Ulitzer
- Ulitzer.com Named Exclusive "New Media" Sponsor of Cloud Computing Conference & Expo
- Ulitzer Live! New Media Conference & Expo
- Adobe’s Aiming ColdFusion at Multiple Clouds
- Eval JavaScript in a Global Context
- Fig Leaf Software to Exhibit at Government IT Conference & Expo
- Cloud Executives Feature on Cloud Computing Expo Power Panel
- Software Flexibility in the Cloud - Part 4 of 5
- Is Microsoft as Free as Open Source?
- Cloud Computing Journal: Adobe to Deliver ColdFusion in the Cloud
- Adobe Reader Sued
- Adobe Unveils LiveCycle Enterprise Suite 2 for Deployment in the Cloud
- Where Are RIA Technologies Headed in 2008?
- Cover Story: How to Increase the Frame Rates of Your Flash Movies
- AJAX World RIA Conference & Expo Kicks Off in New York City
- Your First Adobe Flex Application with a ColdFusion Backend
- Adobe Flex 2: Advanced DataGrid
- i-Technology Blog: Death-Knell For "Rich Media? Hardly!
- Adobe/Macromedia - Microsoft, Look Out!
- How To Create a Photo Slide Show ...
- Adobe Flex Interface Customization - Themes, Styles, Skins
- Personal Branding Checklist
- Has the Technology Bounceback Begun?
- "Real-World Flex" by Adobe's Christophe Coenraets



































